Re: [Flightgear-devel] Some thoughts and ideas (LONG)

[Bernie Bright]

On Fri, 07 Nov 2003 02:22:54 +0200
Paul Surgeon <[EMAIL PROTECTED]> wrote:

> The menu systems could do with some major enhancments.
> A nice menu system for picking airports and aircraft, joystick configuration
> and key mappings would go down well.
> Getting everything menu driven will help a lot. Most people hate playing in 
> shells passing huge lists of arguments to get what they want.

FG Launch Control  is a standalone GUI
app that does some of what you describe.

> We need some nice development tools.
> In particular a full blown scenery editor that one can use to lay down 3D 
> objects (trees/buildings), taxiways, aprons, roads, rivers, etc.
> If it's done in OpenGL then you can make it WYSIWYG.
> One way to do this is to incorporate a "scenery edit" mode into FlightGear 
> like the one in FLY2. You pause the game and go into edit mode and can lay 
> down trees and objects. Then hit unpause and fly around your creation.
> I personally think a seperate editor would be the answer since it won't 
> interfere FlightGear development and one can add as many features as one 
> likes.

FG Scenery Designer  is another
standalone app that lets you modify scenery and place objects.

Cheers,
Bernie

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

Re: [Flightgear-devel] fgrun - runtime error

[Bernie Bright]

On Mon, 10 Nov 2003 00:14:07 +
Richard Hornby <[EMAIL PROTECTED]> wrote:

> This may be one for Erik ...
> 
> I am using FG 0.9.3 CVS version.
> 
> I have compiled fltk and fgrun on SuSE8.2 and both seemed to go fine. I
> compiled both with --with-x and --with threads.  

You don't need to specify --with-x since it is the default.  fgrun doesn't
have a --with-threads option.  fltk-1.1 has a --enable-threads option but I've
never used it.  I suggest you don't either.

> On running fgrun I get the
> following message in the console 
>
> linux:~ # fgrun
> X_DestroyWindow: BadWindow (invalid Window parameter) 0x2ac
> X_TranslateCoords: BadWindow (invalid Window parameter) 0x21
> X_TranslateCoords: BadWindow (invalid Window parameter) 0x21
> 
> and a gray (blank) window entitled FlightGear log (this leaves lines behind
> it when dragged).
> 
> fgrun then hangs.
> 
> This looks like an X-related problem?

fltk comes with several programs in the test directory.  Try some of those to
check your installation.

Bernie

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

Re: [Flightgear-devel] Taxiway editors

[Bernie Bright]

On Wed, 19 Nov 2003 18:15:00 +
Jon Stockill <[EMAIL PROTECTED]> wrote:

> There was much talk a while ago about taxiway editors (ISTR there were at
> least a couple being worked on). How're these progressing, and where can I
> find them? I'm working on a bunch of airfield buildings, and it'd be nice
> to sort out the taxiways at the same time.
> 

I'm working on an AFCAD-like taxiway editor for the FlightGear Scenery
Designer, .  Checkout the
taxiway_editor_3 branch.  Most of the basic editing functionality is present. 
The resultant output is an xml file.

Note, recent changes to fltk v2 means my stuff won't compile any more.  I will
fix it real soon now.

Cheers,
Bernie


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

Re: [Flightgear-devel] Re: New timer code ported onto old

[Bernie Bright]

On Thu, 20 Nov 2003 15:28:49 -0800
Andy Ross <[EMAIL PROTECTED]> wrote:

> Frederic Bouvier wrote:
> > There are people that don't use automake to build flightgear and
> > they would be gratefull if they could continue to build without
> > having to duplicate stuff.
> 
> I'm going to have to start writing clearer, I guess.  Let me say it
> again:
> 
> I *want* to put the nasal.h file into a subdirectory.  Tell me how.
> Editting C++ code is not sufficient.

Judging from the other Makefile.am files, try adding

includedir = @includedir@/nasal

to your Makefile.am and re-run automake, etc.

Bernie

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

Re: [Flightgear-devel] simgear SGSocket returning -1

[Bernie Bright]

On Wed, 26 Nov 2003 16:59:53 -0700
Seamus Thomas Carroll <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> I am trying to recieve a message using SGSocket::read.  
> SGSocket::read returns zero bytes read until about the time 
> I am expecting the first message to be recieved.  From here on 
> SGSocket::read returns that -1 bytes have been read from the socket.
> I have looked around (simgear docs, plib) and I cant find out what the 
> -1 is supposed to indicate.
> 
> Does anyone know?

On unix -1 indicates an error.  The actual error code is in the external
variable errno. Call strerror(errno) to convert errno to a string.

Bernie

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

Re: [Flightgear-devel] FG logo Slovenian flag

[Bernie Bright]

On Thu, 27 Nov 2003 03:43:59 +
Lee Elliott <[EMAIL PROTECTED]> wrote:

> Is there anyway to turn the console output back on?  I've learnt quite a 
> bit from looking at it and it's also helped me sort out a few problems.  
> I understand the desire to make it quieter but I'd like it to be 
> optional.

--log-level=info

Available levels are alert, warn, info, debug and bulk.  alert is the new
default.

Bernie

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

Re: [Flightgear-devel] simgear SGSocket returning -1

[Bernie Bright]

On Wed, 26 Nov 2003 18:04:50 -0700
Seamus Thomas Carroll <[EMAIL PROTECTED]> wrote:

> I output the error and I am getting:
> Transport endpoint is not connected

>From man recv

   ENOTCONN
  The socket is associated with a connection-oriented protocol and
  has not been connected (see connect(2) and accept(2)).

If its the server side that is failing then accept() wasn't called or you are
trying to read from the master socket.  But see below...

> The strange part is if I put '\n' at the end of the message and read with 
> 'readline' the message is successfully recieved.
> 
> Is this a problem with 'read'?

SGSocket::readline() and SGSocket::read() do act differently.  For a
server, readline() correctly handles the accept and reads from the new
socket.  read() also handles the accept but reads from the master socket.
I'm not sure if this is intentional or if its a bug.

Bernie

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

Re: [Flightgear-devel] simgear SGSocket returning -1

[Bernie Bright]

On Thu, 27 Nov 2003 07:23:30 -0600
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:

> Curtis L. Olson writes:
> > Bernie Bright writes:
> > > SGSocket::readline() and SGSocket::read() do act differently.  For a
> > > server, readline() correctly handles the accept and reads from the new
> > > socket.  read() also handles the accept but reads from the master
> > > socket. I'm not sure if this is intentional or if its a bug.
> > 
> > Someone else wrote in reporting a problem here.  THey also said that
> > reading from the new socket fixed the problem in read().  If it seems
> > to make sense, maybe we should make read() read from the new socket?
> 
> It looks like readline() uses sock.recv() for UDP style sockets and
> client->recv() for tcp style sockets.  I will make read() work the
> same way and hope I don't break anything.  Judging from style and lack
> of familiarity, I don't think it was me who wrote the code.

I think I'm responsible for the current code.  I remember rewriting it using
plib.net a couple of years ago.  I agree that read() should work the same as
readline() but I don't remember why it wasn't so in the first place.

Bernie

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

Re: [Flightgear-devel] read not excepting more than one client

[Bernie Bright]

On Fri, 28 Nov 2003 22:45:24 -0700
Seamus Thomas Carroll <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> I have created  a server which has one SGSocket object listening for
> clients that want to connect.  The problem I am having is when a second
> client sends its connect info to the server the server never gets the
> message.  Note that the server is listening using readline and that the
> connection is tcp.  I have tried two different clients and they both work
> if they are the first one to connect.
> 
> Are there any restrictions on a SG_IO_IN socket that I should be aware
> of?  Any other suggestions?
> 
> This problem could be with my code but I want to ask the
> question before I spend a lot of time on looking for the problem.

What you are seeing is normal behaviour for SGSocket.  You might be better
served by using plib.net.  This is what FlightGear uses for the http and prop
servers.  See src/Network/httpd.cxx and src/Network/props.cxx for examples.

Bernie

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

Re: [Flightgear-devel] read not excepting more than one client

[Bernie Bright]

On Mon, 01 Dec 2003 14:59:39 -0700
Seamus Thomas Carroll <[EMAIL PROTECTED]> wrote:

> @[EMAIL PROTECTED] (Swearing),
> 
> Do you know of any websites that I can read the will improve my 
> understaning of sockets?  At my current level of understanding I am having 
> trouble making sense of the pegasus network library and how it is being 
> used in httpd.cxx and props.cxx due to the little documentation on the 
> plib website.

plib.net is based on the python medusa project,
http://www.nightmare.com/medusa/medusa.html.  Other than the source I'm not
aware of any other documentation.  There are lots of good books on socket
programming, anything by the late W Richard Stevens is highly recommended. 
Also try googling for online tutorials.

> Can someone explain why SGSocket restricts the number of clients to one? 

Historical?  Because one client is easy, more than one is hard? :)

> Would it not make more sense to allow up to some maximum number of 
> clients?

Probably, but we'd just end up duplicating what is already handled by
plib.net.  I still think plib.net is your best option rather than banging your
head against SGSocket's limitations.

Bernie

 On Sun, 30 Nov 2003, Bernie Bright wrote:
> 
> > On Fri, 28 Nov 2003 22:45:24 -0700
> > Seamus Thomas Carroll <[EMAIL PROTECTED]> wrote:
> > 
> > > Hi,
> > > 
> > > I have created  a server which has one SGSocket object listening for
> > > clients that want to connect.  The problem I am having is when a second
> > > client sends its connect info to the server the server never gets the
> > > message.  Note that the server is listening using readline and that the
> > > connection is tcp.  I have tried two different clients and they both
> > > work if they are the first one to connect.
> > > 
> > > Are there any restrictions on a SG_IO_IN socket that I should be aware
> > > of?  Any other suggestions?
> > > 
> > > This problem could be with my code but I want to ask the
> > > question before I spend a lot of time on looking for the problem.
> > 
> > What you are seeing is normal behaviour for SGSocket.  You might be better
> > served by using plib.net.  This is what FlightGear uses for the http and
> > prop servers.  See src/Network/httpd.cxx and src/Network/props.cxx for
> > examples.

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

Re: [Flightgear-devel] Checking if there is a connection with netChannel

[Bernie Bright]

On Tue, 02 Dec 2003 20:40:51 -0500
Norman Vine <[EMAIL PROTECTED]> wrote:

> Seamus Thomas Carroll writes:
> > 
> > On the client side I thought about using netChannel::close to inform the 
> > server that the socket is closed but the function is never 
> > called.  netChannel::close is called in the clients destructor but the 
> > destructor is never called because FGGlobals *globals is never deleted 
> > (from what I can tell) which in turn would delete my client. 
> > 
> > Any thoughts on the matter?  Would putting "delete globals" somewhere in 
> > the code which down the line would call netChannel::close() be the
> > solution?
> 
> Easy enough to test
> 
> try moving 
> globals = new FGGlobals;
> 
> out of main,cxx  fgMainInit( int argc, char **argv ) {
> 
> 
> into bootstrap.cxx 
> 
> main(int argc, char **argv) 
> {
> ...
> globals = new FGGlobals;
> 
> // FIXME: add other, more specific
> // exceptions.
> try {
> fgMainInit(argc, argv);
> } catch (sg_throwable &t) {
> // We must use cerr rather than
> // logging, since logging may be
> // disabled.
> cerr << "Fatal error: " << t.getFormattedMessage()
>  << "\n (received from " << t.getOrigin() << ')' << endl;
> exit(1);
> }
>  delete globals;
> 
> }

globals will not be deleted if an exception is caught.  This is a good case
for using std::auto_ptr<>.  Alternatively if globals was an object and not a
pointer it would be destroyed automatically at exit.

Bernie

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

[Flightgear-devel] Ho Ho Ho

[Bernie Bright]

Just discovered the seasonal ufo model.  Nice work Erik.  One problem however,
the sound is messed up.

Bernie

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

Re: [Flightgear-devel] enrty and exit points of main loop

[Bernie Bright]

On Fri, 23 Jan 2004 15:39:23 -0500
Snyder Adam D Civ AFRL/VACD <[EMAIL PROTECTED]> wrote:

> Hello,
>  
> I am trying to add some calls to flightgear's main loop in order
> to set up shared memory and semaphores, and then remove them
> when FG exits.  The easy part is the initialization but I can't
> find a good spot in the code to do any cleanup, due to the
> glutMainLoop.  Any suggestions?

Have you considered registering your cleanup function with atexit()?

Bernie

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

Re: [Flightgear-devel] Fix for compilation error in panel.cxx: `truncf' undeclared

[Bernie Bright]

On Mon, 26 Jan 2004 23:03:50 -0500
Eric L Hathaway <[EMAIL PROTECTED]> wrote:

> Allow me to de-lurk for a minute to report a compilation problem, along 
> with a fix.
> 
> Current (10:00pm EST, 2003-1-26) CVS checkouts of FlightGear fail to 
> compile on my Linux box.  Here is the relevant part of the output from 
> 'make', showing the error:
> 
> --- Begin ---
> g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src 
> -I/usr/X11R6/include  -Wall -O5 -fomit-frame-pointer -ffast-math 
> -funroll-loops -march=athlon -D_REENTRANT -c -o panel.o `test -f 
> panel.cxx || echo './'`panel.cxx
> panel.cxx: In method `const char *FGTextLayer::Chunk::getValue ()
> const':
> panel.cxx:1128: `truncf' undeclared (first use this function)
> panel.cxx:1128: (Each undeclared identifier is reported only once for
> each function it appears in.)
> make[3]: *** [panel.o] Error 1
> --- End ---
> 
> It would appear that the truncf function is not being declared.  I did 
> some searching on Google, and quickly found a thread starting with the 
> following message posted to a glibc mailing list:
> 
> http://sources.redhat.com/ml/bug-glibc/2001-10/msg00015.html
> 
> Apparently, the truncf function was introduced in the C99 standard, and 
> to use such functions in glibc you must define _ISOC99_SOURCE (or 
> _GNU_SOURCE) in order for the functions to be properly declared by 
> .  See the follow-up messages to the above glibc mailing list 
> posting for more info.  I wrote a simple five line C program to test 
> truncf, and indeed it didn't work properly unless I added 
> -D_ISOC99_SOURCE or -D_GNU_SOURCE to the list of arguments to gcc.
> 
> I checked that this compilation problem occurs, and the above fix works, 
> on both a machine running Red Hat 7.3 (glibc-2.2.5, gcc-2.96), and 
> another running Red Hat 9 (glibc-2.3.2, gcc-3.2.2).

Compiles okay on Mandrake 9.2/10.0 (glibc-2.3.3 and gcc-3.3.2).  However this
should really be tested for by the configure script - AC_CHECK_FUNCS(truncf)
and panel.cxx should then contain:

#ifndef HAVE_TRUNCF
inline float truncf (float d) { ...
#endif

Cheers,
Bernie

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

Re: [Flightgear-devel] Re: Fix for compilation error in panel.cxx: `truncf' undeclared

[Bernie Bright]

On Tue, 27 Jan 2004 23:50:56 -0500
Eric L Hathaway <[EMAIL PROTECTED]> wrote:

> Erik Hoffman wrote:
> 
> >Bernie Bright wrote:
> >
> >>/ Compiles okay on Mandrake 9.2/10.0 (glibc-2.3.3 and gcc-3.3.2).  However
> >this/>/ should really be tested for by the configure script -
> >AC_CHECK_FUNCS(truncf)/>/ and panel.cxx should then contain:
> >/
> >I'll add a test for it.
> >
> >Erik
> >
> Erik,
>
> Unfortunately, FlightGear still doesn't compile on RedHat 7.3, even with 
> the above configure script check for truncf (I haven't checked it out on 
> RedHat 9 yet).  I did figure out how to get it to work though (see below).

Perhaps we need to reconsider this whole truncf() thing.  FlightGear is
supposed to be written in C++ not C99.  Maybe we could add an equivalent
function to SimGear.

Bernie


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

Re: [Flightgear-devel] More 0.9.4pre1 feedback

[Bernie Bright]

On Tue, 23 Mar 2004 19:34:38 +0100 (CET)
Frederic BOUVIER <[EMAIL PROTECTED]> wrote:

> Erik Hofman wrote:
> 
> > Frederic BOUVIER wrote: 
> > > Erik Hofman wrote: 
> > > 
> > >>Jon Stockill wrote: 
> > >> 
> > >>>I'll also be including fgrun in the package - is there likely to be a 
> > >>>release newer than 0.4.2 in time to include in the packages? 
> > >> 
> > >>What's wrong with 0.4.2, it's one week old? 
> > > 
> > > Nothing wrong, it's just that we made a few enhancement, like aircraft
> > > alias filtering, display of aircraft name instead of file names,
> > > constant aspect ratio, airport list refresh button or small fix in
> > > resizing. 
> > 
> > 
> > And where's 0.4.3? 
> 
> Not for the moment, should ask Bernie.

Now that you mention it, there have been a lot of updates the past 10 days. 
I will get 0.4.3 out real soon.

Bernie

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

Re: [Flightgear-devel] More 0.9.4pre1 feedback

[Bernie Bright]

On Tue, 23 Mar 2004 17:39:27 + (GMT)
Jon Stockill <[EMAIL PROTECTED]> wrote:

> On Tue, 23 Mar 2004, David Luff wrote:
> 
> > Seems to work fine on Cygwin, apart from the --with-package=PREFIX
> > configuration issues already posted.  Nice job everyone.
> 
> Yup - it's a flawless build on slackware with:
> 
>   plib 1.8.1
>   SimGear 0.5.4pre1
>   FlighGear 0.9.4pre1
> 
> I've not had chance to do much testing yet, but first impressions are
> good.
> 
> I'll also be including fgrun in the package - is there likely to be a
> release newer than 0.4.2 in time to include in the packages?
> 

I've just released 0.4.3.  Changes include:

  * Maintain proper aspect ratio of aircraft preview window.
  * Added control to refresh airport and runway data.
  * Display aircraft description.
  * Smarter handling of aircraft aliases.
  * Fullscreen option at startup.
 
Many thanks to Frederic Bouvier for his input and patches.

Bernie

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

Re: [Flightgear-devel] SDL "early access" implementation

[Bernie Bright]

On Tue, 06 Apr 2004 13:52:28 -0700
Andy Ross <[EMAIL PROTECTED]> wrote:

> Curtis L. Olson wrote:
> > Probably the best short term solution is to make sure we can build
> > with both SDL and glut and let the builder decide?
> 
> Sure.  This should work right now.  The only bits missing are the
> autotools magic to do the detection and set up the makefiles
> appropriately.  I fear autoconf, I really do...  Does someone with a
> more solid handle on these things want to help out? :)

For starters we could change the glut test in configure.ac to something like:
---
dnl Check for SDL if enabled.
AC_ARG_ENABLE(sdl, [  --enable-sdlConfigure to use SDL instead of GLUT],
enable_sdl="yes", enable_sdl="")

if test "x$enable_sdl" = "xyes" ; then
  sdl_version=1.2.0
  AM_PATH_SDL($sdl_version, use_sdl=yes, use_sdl="")
  CPPFLAGS="$CPPFLAGS $SDL_CFLAGS"
  LIBS="$LIBS $SDL_LIBS"
else
 dnl check for glut location
 AC_CHECK_HEADER(GL/glut.h)
 if test "x$ac_cv_header_GL_glut_h" = "xyes"; then
AC_DEFINE([FG_GLUT_H], , [Define as glut.h include location])
 else
AC_CHECK_HEADER(GLUT/glut.h)
if test "x$ac_cv_header_GLUT_glut_h" = "xyes"; then
AC_DEFINE([FG_GLUT_H], , [Define as glut.h include
location])else
echo "Neither GL/glut.h nor GLUT/glut.h found.  Cannot continue"
exit
fi
 fi
fi
---

Bernie

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

Re: [Flightgear-devel] SDL "early access" implementation

[Bernie Bright]

On Wed, 07 Apr 2004 17:20:47 +0200
Erik Hofman <[EMAIL PROTECTED]> wrote:

> Bernie Bright wrote:
> > On Tue, 06 Apr 2004 13:52:28 -0700
> > Andy Ross wrote:
> 
> >>Sure.  This should work right now.  The only bits missing are the
> >>autotools magic to do the detection and set up the makefiles
> >>appropriately.  I fear autoconf, I really do...  Does someone with a
> >>more solid handle on these things want to help out? :)
> > 
> > For starters we could change the glut test in configure.ac to something
> > like:
> 
> Bernie,
> 
> I added another patch to CVS to do this because it caused a number of 
> problems for systems without SDL installed. This approach doesn't rely 
> on SDL provided autoconf macros.

We could add sdl.m4 to FlightGear.  A lot of projects have an m4 directory
to collect such things.  We would then pass that directory to aclocal...
"aclocal -I./m4".

Just updated cvs.  Your fix looks for GL/glut.h when --enable-sdl is
specified.  I thought it was supposed to be either or.

Bernie

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

Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172

[Bernie Bright]

Jim Wilson wrote:
globals->get_tile_mgr()->all_queues_empty() and cur_fdm_state->get_inited())
{
   ^^^
^^^
Same here.

That's a head scratcher.  Never would have thought that would compile like
that.  Learn something new everyday.  
C++ provides keyword equivalents to some operators:
and &&
and_eq  &=
bitand  &
bitor   |
compl   ~
not !
or  ||
or_eq   |=
xor ^
xor_eq  ^=
not_eq  !=
However it seems that we should use the traditional operators to prevent 
msvc from choking.

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

Re: [Flightgear-devel] Spitfire

[Bernie Bright]

Vivian Meazza wrote:
Ampere K. Hardraade wrote

Sent: 26 July 2004 03:13
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Spitfire
To create smoke, we will need two things: smoke emitter and smoke object.
[snip]
Good analysis. How much of this already exists, either in the context of 3d
clouds or AI?
plib.ssgAux has a particle system that can simulate smoke.  Attach one 
to an animation object and there you have it.  Any takers?

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

Re: [Flightgear-devel] Spitfire

[Bernie Bright]

Vivian Meazza wrote:
plib.ssgAux has a particle system that can simulate smoke.  
Attach one 
to an animation object and there you have it.  Any takers?


Someone (David Megginson?) mentioned the particle system when the subject of
smoke was brought up some time ago. 
It may have been me but nothing ever came of it.
Can you point me at some more detail?
What I am proposing is to derive a new class from SGAnimation that 
contains a ssgaParticleSystem object.  The aircraft xml file specifies 
the object's location wrt the airframe reference point and color/type of 
smoke etc.  Individual particles are updated every frame according to 
the laws of physics.  Some experimentation will be involved to determine 
the best number and size of particles.

You can view the ssgaParticleSystem documentation and examples at the
plib website, .  I don't
think the SGAnimation class hierarchy is documented but there are plenty
of derived classes to get ideas from.
This could be a good first project for someone getting involved with 
flightgear.  It is relatively small and self-contained and provides some 
exposure to plib, simgear and flightgear.  Plus it has obvious visual 
feedback.

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

Re: [Flightgear-devel] (no subject)

[Bernie Bright]

David Megginson wrote:
> 
> Jeff writes:
> 
>  > //
>  > I can not find the string " Loading tile" in my fgfs.log file. Can anybody
>  > else see it in here or am I doing something wrong?
>  > //
>  >
>  >
>  >
>  > //
>  > Ref. below (from FAQ 6.5)
>  > //
>  >
>  > Search the output log file for the first occurrence of the string "Loading
>  > tile" and take note of the filename. In the above example, the output line
>  > looks like:
>  >
>  > Loading tile /usr/local/Scenery/w080n40/w076n45/1712601"
> 
> There was a major tile-manager rewrite after I came up with those
> original instructions -- I'm not sure what would work now.
> 

This little program should do the trick:

#include 
#include 

static void usage()
{
std::cerr << "Usage: bucket Latitude Longitude\n"
  << "  where Latitude is in the range [-90,90], and\n"
  << "  Longitude is in the range [-180,180]\n";
}

int
main( int argc, char* argv[] )
{
if (argc != 3)
{
usage();
return 1;
}

double lat = atof(argv[1]);
double lon = atof(argv[2]);

if (lat < -90. || lat > 90.)
{
std::cerr << "Invalid latitude: -90.0 < latitude < 90.0\n";
usage();
return 1;
}

if (lon < -180. || lon > 180.)
{
std::cerr << "Invalid longitude: -180.0 < longitude < 180.0\n";
usage();
return 1;
}

SGBucket b( lon, lat );

std::cout << b.gen_base_path() << "/" << b.gen_index_str() << "\n";
return 0;
}


Compile and run it on linux gives:

$ g++ -o bucket bucket.cxx -lsgbucket -lsgmisc
$ ./bucket 37.62 -121.36
w130n30/w122n37/958434
$

Cheers,
Bernie

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

Re: [Flightgear-devel] Compiler error with Cygwin & SimGear 0.0.16

[Bernie Bright]

"Curtis L. Olson" wrote:
> 
> BERNDT, JON S. (JON) (JSC-EX) (LM) writes:
> > What is MetaKit, anyhow?
> 
> Metakit is a lightweight, simple, embedable database library.  We use
> it to store key/value pairs on disk (airport id vs. the airport info
> for instance.)  It can take several seconds (more on some slower disk
> subsystems) to load all the airport in memory at startup, and it just
> makes a lot more sense to leave it on disk and fetch the pieces we
> need when we need them.
> 

Should also mention that it runs on the Mac and that it has python and
tcl interfaces.

BTW The version of MetaKit we distribute is fairly old now.  2.4.2 is
the latest.

Cheers,
Bernie

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

Re: [Flightgear-devel] New SimGear Class definition

[Bernie Bright]

Erik Hofman wrote:
> 
> Hi,
> 
> Today i have taken some time to take a look at the SimGear code and
> decided it might be time to create a new class definition.
> 
> I'm not sure this is the right time to discuss about it. But then again,
> I always have the feeling it might not be the right time. ;-)
> 
> This is a definition which i feel refelcts the layout of Simgear the
> best. It is not something which should be implemented before next week
> or even the next release. I have the feeling that it is something for
> after the 0.8.0 release of FlightGear.
> 
> If anybody has any suggestions or comments please let me know, so i
> could ask Curtis to publish the best release somewhere on the website
> (just as a confrontation) ;-)
> 
> If things have settled down (and implementing has begun) I was planning
> API documentation in html/what_ever form, which could make life easier
> for new developers.
> 
> Erik
> 

Refactoring SimGear is probably a Good Thing since it has accumulated
some cruft over time and some areas need reworking.  However I don't
think that having bogus top level classes is a good idea.  Instead I
propose we use namespaces.  Perhaps a top level SimGear namespace with
second level namespaces corresponding to the major functional divisions,
as you've outlined.  I think we should eliminate the Misc group as well.

I've been using the Boost libraries (http://www.boost.org) for some time
now and that is what they do.  Portability is one of Boost's goals.  I
also wouldn't mind the opportunity to refactor the compiler
configuration stuff similar to how Boost has done it.

Cheers,
Bernie

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

Re: [Flightgear-devel] New SimGear Class definition

[Bernie Bright]

David Megginson wrote:
> 
> Bernie Bright writes:
> 
>  > Refactoring SimGear is probably a Good Thing since it has accumulated
>  > some cruft over time and some areas need reworking.  However I don't
>  > think that having bogus top level classes is a good idea.  Instead I
>  > propose we use namespaces.  Perhaps a top level SimGear namespace with
>  > second level namespaces corresponding to the major functional divisions,
>  > as you've outlined.  I think we should eliminate the Misc group as well.
>  >
>  > I've been using the Boost libraries (http://www.boost.org) for some time
>  > now and that is what they do.  Portability is one of Boost's goals.  I
>  > also wouldn't mind the opportunity to refactor the compiler
>  > configuration stuff similar to how Boost has done it.
> 
> I agree strongly on namespaces -- they'll eliminate some of our MSVC
> conflicts as well, especially if people avoid using global #defines
> whenever possible.  Do all of our target compilers now support them?
> 

I believe so, although some just ignore namespace declarations
(gcc-2.95!).  My only guideline is Boost, it targets many the same
platforms we do (and some we don't).

Cheers,
Bernie

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

Re: [Flightgear-devel] New SimGear Class definition

[Bernie Bright]

Andy Ross wrote:
> 
>  > I believe so, although some just ignore namespace declarations
>  > (gcc-2.95!).  My only guideline is Boost, it targets many the same
>  > platforms we do (and some we don't).
> 
> The gcc-2.95 I'm using (the one named something different, packaged by
> a distribution vendor I'm afraid to name) supports namespaces just
> fine.  They aren't ignored.  The following, for example, compiles and
> produces the expected results, despite the fact that foo() is declared
> in both namespaces:
> 
> #include 
> 
> namespace a { void foo() { cout << "a\n"; } };
> namespace b { void foo() { cout << "b\n"; } };
> 
> int main()
> {
> a::foo();
> b::foo();
> }
> 

Maybe its just std:: thats ignored.

Bernie

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

Re: [Flightgear-devel] Runway markers

[Bernie Bright]

Alex Perry wrote:
> 
[snip]
> I don't recall whether the taxiways are named in the taxiway file ?
> If not, is there even a field were we can optionally add the names ?

I believe the taxiways are are all named "-" in the original
default.apt.gz.  However there is room for a three or four character
name field.

> Because, generating the yellow/black signs is relatively easy if the
> taxiway database has the names in, and adding the names to an existing
> database of taxiways is a lot quicker than drawing them in the first place.
> 
I've been working on an airport design tool somewhat like X-Plane's
WorldMaker.  Adding taxiway names shouldn't be too difficult to add.

Cheers,
Bernie

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

Re: Including instrumenst was: Re: [Flightgear-devel] c310 Panel

[Bernie Bright]

Norman Vine wrote:
> 
> John Check writes:
> >
> >> Eventually, I guess you could have a separate subdirectory for each
> >> instrument, with a README, etc.  Think of yourself as a fine
> >> craftsman, like a watchmaker.
> >>
> >
> >err.. uhh... umm.. whatever.
> >I'd like to stay away from excessive directories. Maybe if the
> >instruments
> >were stored as tarballs
> 
> I think we are getting close to where we want a more flexible file
> system.  We are already doing something along these lines with
> the Scenery.  ie. when we look for a tile it can either have a .gz
> extension or not and we use the gzf__() functions on the compressed
> files and norman stdio f_() functions if it doesn't.  This concept could
> fairly easily be extended to include directories.
> 

The zlib functions handle uncompressed files so there shouldn't be any
need for FILE* functions.  BTW sg_gzifstream.open(const char* fname)
attempts to open fname with and without the ".gz" extension.

> Kind of like Jar files in Java :-)
> 
> We could even walk both the compressed and the uncompressed
> tree and use the 'newest' file for easy experimentation.
> 
Easy and slow.  I remember someone once saying on this very list that
file opening is a performance killer :)

Cheers,
Bernie

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

Re: [Flightgear-devel] Makefile.am / autoconf problems

[Bernie Bright]

Norman Vine wrote:
> 

[snip]

> I don't use the stock configure scripts so it is kind of hard for
> me to test this but I THINK that we just need to change all
> of the
> 
> INCLUDES += lines in the Makefile.am files to
> INCLUDES =
> 
> The same is true for the
> 
> DEFS += in the src/FDM/JSBSim directories
> change to DEFS =
> 
Its early in the morning for me and I haven't had my first coffee yet
but couldn't we do something like 

DEFS = $(DEFS) -Dfoo

Cheers,
Bernie

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

Re: [Flightgear-devel] Makefile.am / autoconf problems

[Bernie Bright]

"Curtis L. Olson" wrote:
> 
> Bernie,
> 
> I don't believe make allows 'circular' dependencies like that.  I know
> at least some versions do not.  Would be awfully convenient, but I
> don't think it is allowed.
> 
> Curt.
> 
On the other hand "FOO += bar" is an extension not available to all
makes.  We seem to be stuck between a rock and a hard place!

Bernie, now on his second cup of coffee.

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

Re: [Flightgear-devel] Change in Canonical Build Proceedure ???

[Bernie Bright]

Norman Vine wrote:
> 
> It appears as if recent changes in the CVS requires a
> modification in the steps for building FGFS
> 
> 1)  for now, with Cygwin at least,  you NEED to add
> 
> AC_PREREQ(2.13)
> 
> as the first REAL LINE in configure.in
> I am investigating this as it shouldn't be necessary
> 
> 2) Everyone NEEDS to run autoheader as src/include/config.h.in
>  is no longer in the CVS files
> 
> Therefore the canonical sequence for building FGFS from
> a fresh CVS checkout is now
> 
> % rm config.cache
> % aclocal
> % autoheader
> % automake -a
> % autoconf
> % ./configure --YOUR_CONFIGURE_OPTIONS
> % make
> 
I think its time to add an autogen.sh script to bootstrap the build
process.

Bernie

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

Re: [Flightgear-devel] Hello? Is anyone listening?

[Bernie Bright]

Christian Mayer wrote:
> 
> Alex Perry wrote:
> >
> > > (Here, I try to estimate the "download size" when doing
> > > my first ever csv update, on slow time-metered isdn.
> >
> > CVS (it'll take you a few weeks to get the hang of typing it right 8-)
> > is a very efficient method of doing the transfer, but it is not compressed.
> 
> Isn't there a option (I think it's -Z with number = 1...9) to
> compress normal CVS?
> 

-z3 (note case) gives the best compression/performance ratio.  Higher
numbers may produce slightly better compression but require more grunt
on the server.

Cheers,
Bernie

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

Re: [Flightgear-devel] Simgear problem + Misc other stuff

[Bernie Bright]

Norman Vine wrote:
> 
[snip]
>
> Well, I have mentioned this before anyway
> 
> By changing the PPE main() into a function call  say
> int ppe ( ssgContext *ssg, ssgRoot *root, myFGFS  *fgfs )
> 
> where myFGFS contains a few important vars such as lat lon and
> ssgRoot is a scenery node and ssgContext is ssgGetCurrentContext ();
> 
> then by pausing FGFS and calling ppe() and having PPE 'adopt' the
> ssgContext as it's own and assigning the passed Node to be PPE's
> Root Node things just work < well almost > .
> 
> PPE has direct access to everything below the passed node,
> and also knows where we are in the world !
> 
> All of this is possible of course because PPE and  FGFS are built
> from a common substrate,  SSG.
> 
> ie PPE is designed to be a native SSG editor, it's not all there yet
> but the 'hooks' sure are.
> 

Sounds like the basis of a FlightGear plugin for ppe.  Any takers?

BTW I developing a binary scenery loader (.btg) for ppe.  This might be
useful for the mythical scenery/airport designer.

Cheers,
Bernie

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

Re: [Flightgear-devel] Compile error latest CVS

[Bernie Bright]

John Check wrote:
> 
> Latest CVS build dies with following error
> 
> make[4]: Entering directory
> `/home/j4strngs/Repository/FlightGear/src/FDM/JSBSim'
> c++ -DFGFS -I../../.. -I../../../src  -I/usr/local/include
> -I/usr/X11R6/include  -g -O2 -c FGTable.cpp
> FGTable.cpp: In method `void FGTable::Print()':
> FGTable.cpp:228: `ios_base' undeclared (first use this function)
> FGTable.cpp:228: (Each undeclared identifier is reported only once
> FGTable.cpp:228: for each function it appears in.)
> FGTable.cpp:228: parse error before `::'
> make[4]: *** [FGTable.o] Error 1
> 

g++ 2.95.x lacks the Standard's ios_base class.  One messy work around
is demonstrated in simgear/misc/zfstream.hxx.  FWIW I've been working on
an alternative solution using namespaces that is much cleaner.  It
compiles with gcc 2.95.x and 3.0.x, Intel C++ and MSVC6.

Another alternative is that the offending code can be rewritten slightly
more portably using cout.flags() and/or cout.unsetf() though I haven't
fully investigated this.

Cheers,
Bernie

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

Re: [Flightgear-devel] Observations on latest cvs flightgear

[Bernie Bright]

David Megginson wrote:
> 
> Cameron Moore writes:
> 
>  > > The output from SG_INFO to the console (Event states, mouse in
>  > > view/pointer mode, lighting updates and tile updates) can cause
>  > > nasty pauses on Windows 98 even with the console window
>  > > minimised, far worse than on NT on the same hardware.  May I
>  > > suggest that we turn off all the console output during flight by
>  > > default and let users turn it on if they wish.
>  >
>  > I've got a Feature Request item[1] for this on SF.  I seriously doubt
>  > I'll have free time to hack on this before the feature freeze, so if
>  > it's going to get into 0.7.9, someone else is going to have to do
>  > it.
> 
> One of the problems is that JSBSim does its own output outside of the
> SG_LOG infrastructure.  We'll need to modify JSBSim to allow custom
> logging interfaces, and that might be a bit of a tedious chore.
>

You can disable cout by setting its failbit.  Alternatively you could
replace cout's streambuf with one that discards its output.  This won't
work for SG_LOG() since it doesn't use cout.  However I have a new
namespace'd version that does use cout.

Cheers,
Bernie

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

Re: [Flightgear-devel] Fixing Runway Locations & Placing Objects

[Bernie Bright]

Paul Deppe wrote:
> 
[snip]
> I can submit changes to default.apt IAW the FAQ and wait for the next
> scenery generation cycle, but was wondering if there was a way to do it on
> the fly.  I see the .btg.gz in the scenery directory but the .btg
> appears to be a binary file and I couldn't find any documentation on the
> format of this file.
> 

Use the source!  SGBinObject::read_bin() and SGBinObject::write_bin() in
simgear/io/sg_binobj.cxx are the ultimate programmers documentation.

Cheers,
Bernie

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

Re: [Flightgear-devel] Help offered !!!

[Bernie Bright]

David Megginson wrote:
> 
[snip]
> We're also very interested in contributions from C++ coders -- there
> are areas in FlightGear that still need an awful lot of work, and
> perhaps more importantly, there are thousands of lines of existing
> code that need to be reorganized to simplify the architecture and make
> it more consistent.  If you're interested in 3D work or GIS, you might
> want to look at our scenery-generation software TerraGear, which has
> been sadly neglected of late.

Perhaps we need a TODO file in cvs containing specific suggestions
and/or small project ideas.  Something like the projects page on the
website but with more detail.

Cheers,
Bernie

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

Re: [Flightgear-devel] ancient 'ascii' scenery format

[Bernie Bright]

Wolfram Kuss wrote:
> 
> Curt asked:
> 
> >Is anyone still using this ancient file format?
> 
> Yes.
> 
> >Does anyone have any objections to ending support
> >in flightgear for it?
> 
> Is it easy to create a atg2btg converter (I only have btg2atg) or does
> someone write a btg importer/exporter to plib? If so, then it is
> completely ok by me.
> 

I've been working on a btg importer for plib/ppe.  Once I've got
something useable I'll announce it on the appropriate mailing lists.

atg2btg should be trivial to code.  I might even have one sitting around
some place.

Cheers,
Bernie

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

Re: [Flightgear-devel] C++ Template Question

[Bernie Bright]

David Megginson wrote:
> 
> I have a question for the C++ heads.  Let's assume that I have
> something like this:
> 
>   template 
>   T
>   Binding::get_value () const
>   {
> return (_obj.*_getter)();
>   }
> 
> assuming
> 
>   C &_obj;
>   T (C::*_getter)() const;
> 
> This always gets instantiated correctly when I included it inline in
> the header file, but not when I move the definition out to the cxx
> file.  Is that an inherent limitation of templates?  I cannot
> pre-instantiate all the templates I might need in the cxx file,
> because I don't know what classes people will use this with.
> 
> I'll appreciate any help.
> 
I believe this is a limitation with templates.  Until all compilers
support the 'export' keyword, template function definitions must be
defined in a header file.

Cheers,
Bernie

Obligatory reference:  Perhaps Boost.Function from www.boost.org is
worth looking at?

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

Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Cockpit panel_io.cxx,1.36,1.37

[Bernie Bright]

Cameron Moore wrote:
> 
> * [EMAIL PROTECTED] (Curtis L. Olson) [2002.03.21 08:58]:
> > Index: panel_io.cxx
> > ===
> > RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Cockpit/panel_io.cxx,v
> > retrieving revision 1.36
> > retrieving revision 1.37
> > diff -C2 -r1.36 -r1.37
> > *** panel_io.cxx  19 Mar 2002 16:12:15 -  1.36
> > --- panel_io.cxx  20 Mar 2002 14:57:31 -  1.37
> > ***
> > *** 296,300 
> > }
> >
> > !   if (propName != "") {
> >   target = fgGetNode(propName.c_str(), true);
> > }
> > --- 296,300 
> > }
> >
> > !   if (propName != (string)"") {
> >   target = fgGetNode(propName.c_str(), true);
> > }
> 
> As Bernie has mentioned before[1], this should be:
> 
>   if (!propName.empty()) {
> 
> And for someone who has time, there's plenty more of these to be fixed:
> 
> $ cd FlightGear/src/
> $ find . -type f -name '*.[ch]??' | xargs grep -n '[=!]= ""'
> ./ATC/ATCmgr.cxx:112: if(last_comm1_ident != "") {
[snip]

Just to make life more complicated, the latest changes to the property
system return const char* instead of std::string.  Don't know if it will
have any impact on this todo item.

Bernie

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

Re: [Flightgear-devel] inlining

[Bernie Bright]

Andy Ross wrote:
> 
> FWIW, my interest in un-inlining stuff has nothing to do with runtime
> performance at all.  What I want to see is for FlightGear to compile
> in something under 20 minutes on my machine.  Some parts are really
> just terribly slow to build.  JSBSim and UIUC are big culprits here,

Personally I only ever fly the default fdm so compiling the others is a
waste of my time and resources.  Maybe we should add an argument to
configure to select which FDM(s) to compile:

--with-fdm=all   the default, compiles all fdm modules
--with-fdm=yasim compiles only the specified fdm

Cheers,
Bernie

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

Re: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0

[Bernie Bright]

Jonathan Polley wrote:
> 

> With the irregularity that I am having problems with "using XXX" I get the
> feeling that there is something wrong with a header someplace, or a
> #define.  Not all modules generate the error, and others (namely the
> updates, and only the updates, to JSBSim) blow body parts across the room.
>I can change the behavior of JSBSim by rearranging the #includes in some
> of the modules, but I cannot get rid of the errors.
> 
> Is anyone else building under MSVC 6.0 (or other MSVC compiler)?
> 

Moving using std::sort after #include  fixes the problem in
props.cxx.

I build under MSVC6 occasionally though generally I use linux.  However
I was responsible for resolving some of the early portability issues.

Cheers,
Bernie

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

Re: [Flightgear-devel] Conditional fgEVENTs

[Bernie Bright]

[EMAIL PROTECTED] wrote:
> 
> Is anyone working with the fgEVENT in Time/event.hxx and related classes?
> Since our project is a particular simulated space mission, I've been
> looking at how to cause certain events (text displays and sounds, mainly)
> based on conditions in the property tree. I didn't find anything to do
> exactly that, but with fgEVENT and FGConditional, it should be pretty
> simple to implement. Here's a diagram, with the new parts shaded and
> blue:
> 
> http://genesis.cs.utc.edu/~mpaschal/work/gems/conditionalEvents06.png
> 
> Is this reasonable? Since these conditional events are necessary for how
> we're working our mission, I intend to write this for our use even if
> it's not useful generally.
> 
> One implementation worry is that passing a parameter as part of an
> fgCallback appears only partially implemented. This feature would be
> greatly useful so that we could call a 'play sound' function with a
> particular sound as a parameter rather than having separate 'play sound
> x' and 'play sound y' functions--but I would have to whip out the C++
> books for a while to be able to fix it myself without breaking the
> existing events, assuming it's possible at all.
> 
> Your advice is greatly appreciated.
> 
An fgEVENT is a function that is executed every X milliseconds.  Once
per frame the event queue is scanned and any events whose interval has
passed is executed.  FWIW the current implementation is fairly old and
crufty.  I have a newer version that replaces fgCallback with
boost::function.  Boost::bind can also be used which allows arbitrary
parameters to be passed to the function when it is executed.

FGConditional, I believe, is part of the property sub-system but until
now no one has suggested combining them with the event sub-system.

Cheers,
Bernie

PS see http://www.boost.org for more details on boost::function and
boost::bind

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

Re: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0

[Bernie Bright]

Jonathan Polley wrote:
> 
> On Thursday, March 21, 2002, at 03:37 AM, Erik Hofman wrote:
> 
>  Jonathan Polley wrote:
> 
>   After getting SimGear to build under MSVC 6.0 (thanks Christian), I moved 
>on to getting all of FlightGear to build. For some reason, MSVC does not like JSBSim 
>(over 1200 errors generated) but I had no problem under RH 7.1 (as usual). I expect 
>that everything is a snow ball started from the errors in FGPropertyManager.h.
>   The full build result file can be found at:
>   http://homepage.mac.com/eq_fidget/FG_Dox/FlightGear.html
> 
>  It's just a matter of removing (*all*) the 'FGPropertyManager::' sections 
>within the class (or file).
> 
>  Erik
> 
> When I do that, it complains about the multiple definitions of 'Tie.' When it starts 
>failing the compile, it is on the second, and subsequent, definitions of 
>'FGPropertyManager::Tie.'
> 
> When I comment out *ALL* instances of 'Tie' (however you want to define it), I still 
>get a major explosion which makes absolutely NO sense:
> 
[snip]

You're right, it doesn't make any sense.  Perhaps you commented out too
much?

Anyways, I've managed to compile a recent FlightGear JSBSim.  The
problems I encountered seem to be that MSVC can not deduce which
overloaded member function to call:

Compiling...
FGAerodynamics.cpp
c:\src\flightgear\src\fdm\jsbsim\fgaerodynamics.cpp(229) : error C2661:
'Tie' : no overloaded function takes 4 parameters

Adding an ugly cast fixes the problem:

  PropertyManager->Tie("forces/fbx-aero-lbs", this,1,
(double (FGAerodynamics::*)(int) const) &FGAerodynamics::GetForces);

A similar cast is required on every pointer to member function that
takes an index, probably because there is a similar named member
function that takes no index:

class FGAerodynamics : public FGModel {
...
  FGColumnVector3& GetForces(void) {return vForces;}
  inline double GetForces(int n) const {return vForces(n);}

On that note, since we are taking a pointer to a member function, the
compiler must emit a function body.  Thus the member function can't be
inline.  This may help decide which functions to inline.

Cheers,
Bernie

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

Re: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0

[Bernie Bright]

Jonathan Polley wrote:
> 
> While we are on the subject of MSVC, were you able to link with the files from
> CVS?  In addition to the new files, I had to modify some other parts to
> the .dsp file(s) to make a link.

I have compiled and linked a recent (one or two day old) cvs snapshot
using MSVC6.  Some customizations are required to the project file,
library paths for example.  I did have problems linking with multiply
defined symbols.  It turned out that plib is compiled multi-threaded
whilst everything else is single threaded.  Recompiling plib solved the
problem.

The workspace and project files are auto generated.  I wrote the script
that generates them.  If you have specific requests or ideas in that
area then contact me offline.  There are some minor tweaks I was about
to submit to Curt but I can hold off for a day or two.

Cheers,
Bernie

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

Re: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0

[Bernie Bright]

Jon Berndt wrote:
> 
> > > Adding an ugly cast fixes the problem:
> > >
> > >   PropertyManager->Tie("forces/fbx-aero-lbs", this,1,
> > > (double (FGAerodynamics::*)(int) const) &FGAerodynamics::GetForces);
> >
> > I'll roll that change into my copy until it gets made permanently.  While
> 
> We'll do a little investigating, first. I want to understand why MSVC is
> having problems, first, when no other compiler appears to be complaining. We
> want to remain as cross-platform/cross-compiler compatible as possible, but
> as a matter of policy, I am extremely hesitant to make crutches in our code
> to fix a crippled compiler - if, indeed, it turns out to be a problem with
> MSVC. Do you have any explanatory backup for why MSVC isn't working with
> this? I know this sounds rude of me, but I hope you can see where I am
> coming from.

I'm not sure if it is actually a problem with MSVC or if other compilers
have different rules when it comes to taking the address of an
overloaded function.  I have encountered this exact same problem before,
with even gcc requiring a cast to disambiguate pointers to overloaded
member functions.  Note that the cast is portable, I've tested with gcc
2.95.3 at least.

The only explanation I can offer is that &FGAerodynamics::GetForces is
ambiguous given the declaration

class FGAerodynamics : public FGModel {
  FGColumnVector3& GetForces(void);
  double   GetForces(int n) const;
  ...

The cast is a hint to the compiler which of the two GetForces() member
functions we are taking the address of.  I have no idea why MSVC can't
deduce the correct member while other compilers can but that is the
essence of the problem as I understand it.

Cheers,
Bernie

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

Re: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0

[Bernie Bright]

Norman Vine wrote:
> 
> Jon, I don't think there is a 'conforming' compiler yet, and MSVC6 is
> several years
> old and I wonder how well the then current gnu stdlib++ would have handled
> that
> construct :-))
> 

I believe Comeau is 99.9% conforming but it is not free.  I also believe
that MSVC7 is much much better, they are using boost
(http://www.boost.org) as one of their conformance acceptance tests, as
are the gcc 3 crew.

> That said I will agree that MSVC6 even with all the service packs
> is a 'little' behind most of the others in being able to handle some of
> the more 'arcane' bits of C++.
> 
> There is STLPort however that should work just with just about any compiler
> even MSVC :-)
> 
True, however this particular problem is compiler related not library
related for once.

Cheers,
Bernie

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

Re: [Flightgear-devel] MicroSoft Visual C++ Deficiencies

[Bernie Bright]

Jonathan Polley wrote:
> 
> On Sunday, March 24, 2002, at 11:32 PM, Norman Vine wrote:
> 
> > FYI
> >
> >  http://hammer.prohosting.com/~yotam/software/msviscxx/
> >
> > ___
> > Flightgear-devel mailing list
> > [EMAIL PROTECTED]
> > http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> >
> 
> I think that will be added to chapter 150 of my book on "Why I Love Using
> Microsoft Products."  My guess is that we have something related to the
> "Function Template Parameter" problem.

Although the errors I got correspond to "Confused by Template Forward
Declaration".

Bernie

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

Re: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0

[Bernie Bright]

Tony Peden wrote:
> 
> It's unfortunate but I think we're going to have to incorporate this
> cast.
> 
> However, I do think we could clean it up a bit with a pre-processor
> define:
> #define AEROINTFUNC double (FGAerodynamics::*)(int) const
> then
> PropertyManager->Tie("forces/fbx-aero-lbs", this,1,
>  (AEROINTFUNC)&FGAerodynamics::GetForces);
> 
> Hopefully, its still clear that that is a cast.
> 
> Assuming Jon does not object, I will accept patches that look like the
> above.

Okay, I'll make the changes to the current JSBSim cvs snapshot (not the
one in FlightGear) and send you the patches.  However I might try a
typedef instead of a macro.

Cheers,
Bernie

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

Re: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0

[Bernie Bright]

Tony Peden wrote:
> 
> 
> Bernie, Johnathan: have you had similar difficulties compiling
> src/Controls/controls.cxx?
> 
> (it also ties indexed object methods)

Compiles just fine.  The difference is that the member function being
tied is unambiguous.

Cheers,
Bernie

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

Re: [Flightgear-devel] MSVC6 - Current cvs - 25 March

[Bernie Bright]

Geoff McLane wrote:
> 
> Hi,
> 
> I can see nothing 'wrong' in the construct in
> FGPropertyManager.h that should give 'pause'
> to a compiler ... as other compilers have proved.
> 

The construct is legal Std C++.  MSVC is at fault.

> You will note msvc does NOT require any such
> 'agressively additional casting' when used in the
> 5 parameters case -
> 
> That is, from say FGAircraft.cpp -
> This FAILS 
>   PropertyManager->Tie("metrics/eyepoint-z-ft", this,3,
>&FGAircraft::GetXYZep);
> 
> While this WORKS  Why ???
>   PropertyManager->Tie("metrics/alpha-max-deg", this,
>&FGAircraft::GetAlphaCLMax,
>&FGAircraft::SetAlphaCLMax,
>true);
> 
> The difference is in the 'casting' of the (*getter).
> 
> In the second the getter is 'double get()' style, while
> the 'other' getter is 'double get(index)' style, and the
> compiler misses the connection ...
>

The difference is that there are two FGAircraft::GetXYZep functions:

class FGAircraft {
  inline FGColumnVector3& GetXYZep(void) { return vXYZep; }
  inline double GetXYZep(int idx) const { return vXYZep(idx); }

MSVC is unable to disambiguate them given that the
FGPropertyManager::Tie prototype is visible and that "V
(T::*getter)(int) const" is an exact match when T=FGAircraft and
V=double.  Removing the inlines doesn't help either.  The conclusion is
that MSVC is wrong but we can help it by providing a "hint" in the form
of an appropriate cast.

Your second example works because there is only one
FGAircraft::GetAlphaCLMax().  As a test I added an overloaded
"GetAlphaCLMax(int) const" member function and got the same compilation
error.

Cheers,
Bernie

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

Re: [Flightgear-devel] MSVC6 - Current cvs - 25 March

[Bernie Bright]

Geoff McLane wrote:
> 
> Also, such function additions gives the compiler/linker a
> chance to really make this 'inline', since the double value
> could be 'addressed' in simple lines, when loaded, like
> moveax, [0x12345678]; get that double
> movedx,[0x12345678+4]
> or in 64-bits
> lodreg1, [0x1234567812345678]; load double
> which is all we can ask for 'inline' ...
> 

Except that by taking the address of the function we force the compiler
to emit a function body despite the inline qualifier.

Cheers,
Bernie

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

Re: [Flightgear-devel] I can't compile flightgear0.7.9 in Microsoft Visual C++ 6.0

[Bernie Bright]

way lee wrote:
> 
> I meet a problem when I compile flightgear0.7.9. The VC
> compiler told me that there was no mk4vc60s.lib.
> 
>  I can't find it in CD-image.
> 
> Can you tell me where is it?
> 

mk4vc60s.lib is the Metakit library.  The source is included as a
separate tar.gz file in the SimGear tar file.  You will need to un-tar
and compile it yourself.

Bernie

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

Re: [Flightgear-devel] MSVC6 Build Progress

[Bernie Bright]

David Megginson wrote:
> 
> Jonathan Polley writes:
> 
>  > I reverted input.hxx back to what was in CVS and moved the enumeration
>  > from being private to public and MSVC now likes using an enumeration
>  > element to define an array.  Why the compiler cares about an enum being
>  > private vs. public, I will never know (although I have seen this behavior
>  > before).  I also brought in the newest input.cxx and I can now run
>  > FlightGear again.
> 
> Does it still work if the enum is protected?  I'd like to keep things
> as well encapsulated as possible.
>

You can keep the enum private if you add the following declarations
immediately afterwards:

  struct mouse;
  friend struct mouse;

It seems that MSVC doesn't grant the nested mouse decl. any special
access privileges to its surrounding class.

Bernie

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

Re: [Flightgear-devel] MSVC6 Build Progress

[Bernie Bright]

Bernie Bright wrote:
> 
> You can keep the enum private if you add the following declarations
> immediately afterwards:
> 
>   struct mouse;
>   friend struct mouse;
> 
> It seems that MSVC doesn't grant the nested mouse decl. any special
> access privileges to its surrounding class.

Following up my own reply, I believe that MSVC is correct and that gcc
is wrong.  According to Stroustrup and the Standard, members of a nested
class have no special access to members of the enclosing class, ie a
nested class can only access public members of its enclosing class.

Cheers,
Bernie

PS I notice this change has been commited.  Thanks.

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

Re: [Flightgear-devel] Simgear w/OpenGC question

[Bernie Bright]

Damion Shelton wrote:
> 
> Hi all,
> 
> Some time back John started using Simgear in OpenGC to form the basis for
> our local nav database. Although this works fine under Cygwin and Linux,
> until recently I had problems with it under Windows. The problem turned out
> to be the following:
> 
> The two libraries that OpenGC links with, besides Simgear, are FTGL and
> Freetype 2.06. Under Windows, both of these are set to build with the /MD
> (multithreaded DLL) compiler option. Simgear is set to build with the /ML
> (single-threaded) libraries. Linking with both of these simultaneously was
> causing more than a few linker errors (OpenGC was set up to link using /MD
> as well). Without Simgear, everything worked fine.
> 
> By rebuilding FTGL and OpenGC with the /ML library flag, everything seems
> happy. Although there are no immediate plans to support multithreading in
> OpenGC, it would be more convenient to Windows users if they did not have to
> modify the build process in order to allow compatibility with Simgear.
> 
> Any Windows/Simgear gurus out there have any suggestions?

Its trivial to recompile SimGear multithreaded (/MT).  I can make this
the default since it is the also the default for plib and metakit.  Note
that SimGear cannot be compiled as a DLL.

Bernie

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

Re: [Flightgear-devel] Heads up: Boost - http://www.boost.org/

[Bernie Bright]

Christian Mayer wrote:
> 
> "Curtis L. Olson" wrote:
> >
> > Bernie Bright has submitted a simplified boost distribution for
> > SimGear and I have committed it to CVS.  The boost web page is here:
> >
> > http://www.boost.org/
> >
> > We will begin depending on this package soon.
> 
> Well, *I* don't really understand what boost is usefull for.
> 
> Can somebody tell me what boost does and why it's important for us,
> please?

Boost was begun by members of the C++ Standards Committee Library
Working Group, although membership has expanded to include nearly two
thousand members of the C++ community at large.  Its aim is to develop
"existing practice" and provide reference  implementations of possible
future additions to the C++ Standard Library.  Several Boost libraries
have already been presented to the library working group and have met
with a favorable response (that is, it is quite likely that they will
become part of the next C++ standard library).

I have asked Curt to include a subset of Boost that includes just
Boost.Function and Boost.Bind (plus required support and configuration
files).  These are all header files so there is nothing to compile.

Boost.Function is a family of class templates that implement function
objects.  It generalises the idea of callback functions such that free
functions and member functions are treated identically.  This means that
anywhere we store a function pointer or an object pointer plus
pointer-to-member-function we can store a single boost::function object
instead.

Boost.Bind is a generalisation of std::bind1st(), std::bind2nd() and
std::mem_fun().  It is used in conjunction with Boost.Function to "bind"
an object and a pointer to a member function into a single function
object.  It is a smarter and more elegant replacement for our
fg_callback.

Boost has a lot to offer if you are doing any serious C++ development. 
For example smart pointers, a regex library, compile time assertions and
threads have all been presented to the committee.  Remember, what is in
Boost today may appear in the C++ standard tomorrow :)

Cheers,
Bernie

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

Re: [Flightgear-devel] Boost problems

[Bernie Bright]

Erik Hofman wrote:
> 
> What should we do about this?
> 
> Erik
> 

Seems to be boost related.  What compiler and platform?  I seem to
remember you are running an old IRIX system.  Could you check
http://www.boost.org/status/compiler_status.html to see if your platform
is supported and if there are work arounds.  If the worst happens we may
have to back out the recent boost additions.

Bernie

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

Re: [Flightgear-devel] Problem with templates

[Bernie Bright]

Marcio Shimoda wrote:
> 
> > Unfortunately this doesn't seem to be the complete error message, so I
> > cannot se what's happening.
> >
> > You might want to post the complere error message, together with the OS
> > and compiler you are using.
> >
> > Erik
> >
> 
> Well, this is a long warning/error message...
> I'm using MSVC6 and Win98.
> 
> "Compiling...
> fg_fx.cxx
> c:\arquivos de programas\microsoft visual studio\vc98\include\map(27) :
> warning C4786:
> '??R_Kfn@?$map@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@
> @PAUsample_ref@@U?$less@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@
> D@2@@std@@
> @2@V?$allocator@PAUsample_ref@@@2@@std@@QBEABV?$basic_string@DU?$char_traits
> @D@std@@V?$allocator@D@2@@2@ABU?$pair@$$CBV?$basic_string@DU?$char_traits@D@
> std@@V?$allocator@D@2@@std@@PAUsample_ref@@@2@@Z' : identifier was truncated
> to '255' characters
> in the browser information

Try adding #include  as the first include statement
of fg_fx.cxx.  Warning C4786 is harmless, identifier too long, but it
obscures any real warnings and errors.

Bernie

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

Re: [Flightgear-devel] Moving carrier, and Repositioningquestions

[Bernie Bright]

Jon S Berndt wrote:
> 
> On Fri, 5 Apr 2002 13:00:00 -0500
>   David Megginson <[EMAIL PROTECTED]> wrote:
> >Jon S Berndt writes:
> 
> >That's actually becoming a bit of a problem -- I couldn't use FGModel
> >for the 3D model either because JSBSim had already taken it. As Andy
> >keeps reminding us, it would be a good idea to put JSBSim and possibly
> >SimGear into their own namespaces to avoid conflicts like these.
> 
> Yeah, I've considered that for some time, just haven't
> gotten around to it. But, I guess if it's causing so many
> problems, maybe we need to just go ahead and do it.
> Another reason I have waited is because even though I know
> how to use stuff in other namespaces, I'm not positive
> that I know how to go about putting our stuff into a
> namespace. Can anyone explain this to me?
> 

Its pretty simple.  Just wrap the contents of all your header and source
file with:

namespace JSBSim {
  ...
}

Users of the your classes would refer to them as JSBsim::Foo.  I would
advise against a "using namespace JSBSim;" directive since that
re-introduces the problem we are attempting to solve.  Even a "using
JSBSim::Foo;" declaration is risky if Foo is declared elsewhere.

I have experimented with namespaces in SimGear with good effect.  For
instance, SGEphemeris wraps quite nicely into its own namespace:

namespace simgear {
  namespace ephemeris {
class SGEphemeris {...};
class CelestialBody {...};
class Venus : public CelestialBody {...};
  }
}

Only a couple of minor changes to FlightGear were necessary, references
to SGEphemeris become simgear::ephemeris::SGEphemeris.

With namespaces we could even drop the SG prefix. 

Cheers,
Bernie

PS I think YASim is in its own namespace so you could look there for
inspiration.

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

Re: [Flightgear-devel] Boost problems

[Bernie Bright]

"Curtis L. Olson" wrote:
> 
> Bernie Bright writes:
> > Erik Hofman wrote:
> > >
> > > What should we do about this?
> > >
> > > Erik
> > >
> >
> > Seems to be boost related.  What compiler and platform?  I seem to
> > remember you are running an old IRIX system.  Could you check
> > http://www.boost.org/status/compiler_status.html to see if your platform
> > is supported and if there are work arounds.  If the worst happens we may
> > have to back out the recent boost additions.
> 
> Looks like the stock sgi compiler tanks on just about all the boost
> modules including bind and function.  clib (whatever that is) and
> STLport seem to resolve the problem for these modules and most of the
> other ones.

clib is new to me too, but I'm no irix expert.  My guess is that it
provides  style headers which was reported as a problem by
Erik.  STLport appears the way to go though.

Bernie

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

Re: [Flightgear-devel] Boost problems

[Bernie Bright]

Erik Hofman wrote:
> 
> Erik Hofman wrote:
> 
> >> clib is new to me too, but I'm no irix expert.  My guess is that it
> >> provides  style headers which was reported as a problem by
> >> Erik.  STLport appears the way to go though.
> >
> >
> > While I agree that STLPort may be a good thing, I'm a bit worried about
> > the fact that there are a *lot* of IRIX related fixes in the code, end
> > we may need even more fixes to support STLPort (also).
> >
> > I'll take a look at both clib and STLport and see what might be best.
> 
> STLport is no option. I would need the latest MipsPro compiler from SGI
> (for about $750,-). I havn't found clib anywhere.
> 
> I'm lost now.
> :-(

clib is a compatability library that comes with boost.  I wasn't aware
of it until now.  Its purpose is to provide the  form of C
standard headers.  Since its only 3K gzipped I've attached it here.

I've also had a quick look at the boost regression test suite and the
command line it uses for compiling is:

CC -c -LANG:std -OPT:IEEE_NaN_inf=ON -woff 1234
-I../boost/compatibility/cpp_c_headers 

This doesn't mean much to me but it may be of some use.  I have a
feeling though that your compiler may be too old to compile boost.  Is
gcc 2.95 an option?

Cheers,
Bernie


clib.tar.gz
Description: GNU Zip compressed data

Re: [Flightgear-devel] Boost?

[Bernie Bright]

> John Wojnaroski wrote:
> 
> Okay, I need a boost ;-0
> 
> Downloaded the files. Tried the header files in several locations, but
> ./configure would not (could not) find them
> Is it /usr/include or ~/SimGear/ or ~/SimGear/simgear/ or
> /usr/local/include/ or..?

You can install them where ever you like as long, then add the include
path to CXXFLAGS before calling configure:

  CXXFLAGS="-I" ./configure

If you are using gcc then /usr/local/include is an obvious location
since gcc looks there anyway.  In this case you don't need the CXXFLAGS
trick.

> Do you need more than the headers? like libraries, or are the headers
> self-contained as noted in the install manual?

The subset of boost I've supplied is headers only.  There is nothing
else to compile or install.

Bernie

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

Re: [Flightgear-devel] MSVC Still not Building

[Bernie Bright]

To avoid this problem in future, maybe we should define a macro in
.  Something like:

#ifdef SG_NO_INCLASS_MEMBER_INITIALIZATION
# define SG_STATIC_CONSTANT(type, assignment) enum { assignment }
#else
# define SG_STATIC_CONSTANT(type, assignment) static const type
assignment
#endif

Usage then becomes:

class Foo {
  SG_STATIC_CONSTANT(int, FG_MAX_ENGINES = 4);
  ...
}

which expands to either
 static const int FG_MAX_ENGINES = 4;
or
 enum { FG_MAX_ENGINES = 4; };

I think the problem with Norman's solution is that you can't use the
value later in the class declaration, as an array size for example.

Cheers,
Bernie

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

Re: [Flightgear-devel] FYI: Re BOOST

[Bernie Bright]

Jon S Berndt wrote:
> 
> This month's issue (MAY 2002) of C/C++ User's Journal
> contains the article: "The Boost.Threads Library". The
> issue focuses on multithreading.

Matt Austern and Herb Sutter regularly mention Boost in their articles
and at the C++ experts forum at http://www.cuj.com/experts/.  Both have
contributed code and/or criticisms.

Bernie

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

Re: [Flightgear-devel] Ambient lighting

[Bernie Bright]

"Curtis L. Olson" wrote:
> 
> David Megginson writes:
> > All ambient lighting has suddenly vanished from my FlightGear, even
> > with my previously-built binary. I still see the 2D panel and the
> > runway lights, but nothing else, no matter what the time of day.
> > Other 3D programs like Blender and TuxRacer are still working fine.
> > Has anything else ever noticed a problem like this?
> 
> Yes, I'm seeing that too.  Bernie, I wonder if it has something to do
> with the recent event manager changes?  The scene recovers after the
> first time update (30 seconds into the sim run.)  I think before, the
> event manger must have run the routine at schedule time and then at
> the requested interval after that.

Your analysis is correct.  The old event manager executes an event when
it is registered and then subsequently every 'interval' milliseconds.  I
can replace the old behaviour but wonder if I should.  IMO registering
an event to be run every x millseconds doesn't imply running it
immediately.  Thoughts?

BTW David, Boost is no longer used.  Some older compilers were having
trouble with Boost's advanced template usage.

Bernie

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

Re: [Flightgear-devel] Ambient lighting

[Bernie Bright]

"Curtis L. Olson" wrote:
> 
> Bernie Bright writes:
> > Your analysis is correct.  The old event manager executes an event when
> > it is registered and then subsequently every 'interval' milliseconds.  I
> > can replace the old behaviour but wonder if I should.  IMO registering
> > an event to be run every x millseconds doesn't imply running it
> > immediately.  Thoughts?
> 
> It seems reasonable to me to run the task once when it is registered
> and then subsequently at the requested interval.
> 
Okay.  Here's a patched FGEventMgr.cxx that executes the callback upon
registration.

Cheers,
Bernie


FGEventMgr.cxx
Description: application/unknown-content-type-cxxfile

Re: [Flightgear-devel] Ambient lighting

[Bernie Bright]

Alex Perry wrote:
> 
> Personally, I've always preferred that event registration takes two
> parameters; the first delay time and the repeat delay time.
> This lets you do one-shot as well as immediate and non-immediate modes.
> Can we do something like that with Boost in future ?
> Obviously we can support it right now if we want to.

I like that idea.  Something like setitimer() and the itimerval struct
under Unix.  I'll investigate adding an initial delay time in addition
to the repeat interval.

Cheers,
Bernie

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

Re: [Flightgear-devel] Update Missing in config.h-msvc6

[Bernie Bright]

"Curtis L. Olson" wrote:
> 
> Ugh, that's ugly.  The configure script takes care of this
> automatically with unix/cygwin.  Could something be done with the
> am2dsp.pl script?

Tricky!  The am2dsp.pl script doesn't touch config.h.in.  However I
could get the AM_INIT_AUTOMAKE version string from configure.in
("0.7.10pre1" or whatever), concatenate it with "MSVC6-WIN32-" and then
pass it on the compiler command line, -DFLIGHTGEAR_VERSION=...  Let me
investigate further before I decide on a solution.

Bernie

> Jonathan Polley writes:
> > The 0.7.10 version of config.h-msvc6 reports itself as
> >
> > #define FLIGHTGEAR_VERSION "MSVC6-WIN32-0.7.9"
> >
> > Which gets printed on startup.  It also exports the following version
> > constant.
> >
> > #define VERSION "0.57"
> >
> >
> >
> > Jonathan Polley
>

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

Re: [Flightgear-devel] Update Missing in config.h-msvc6

[Bernie Bright]

Bernie Bright wrote:
> 
> "Curtis L. Olson" wrote:
> >
> > Ugh, that's ugly.  The configure script takes care of this
> > automatically with unix/cygwin.  Could something be done with the
> > am2dsp.pl script?
> 
> Tricky!  The am2dsp.pl script doesn't touch config.h.in.  However I
> could get the AM_INIT_AUTOMAKE version string from configure.in
> ("0.7.10pre1" or whatever), concatenate it with "MSVC6-WIN32-" and then
> pass it on the compiler command line, -DFLIGHTGEAR_VERSION=...  Let me
> investigate further before I decide on a solution.
> 

Further investigation reveals that FLIGHTGEAR_VERSION is defined in
src/Include/version.h.  If we just want the version without the
MSVC6-WIN32- prefix then we can just delete the relevant line from
config.h-msvc6.  Otherwise I can trivially modify am2dsp as above.

Bernie

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

[Flightgear-devel] YASim compile warning

[Bernie Bright]

Compiling YASim with the new Intel C++ V6 compiler gives the following
warning:

../../../../src/FDM/YASim/Model.cpp(260): warning #175: subscript out of
range
  float dist = ground[4] - Math::dot3(ground, _wingCenter);
   ^

Bernie

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

Re: [Flightgear-devel] Re: Attaching to the network interface

[Bernie Bright]

"Scott G. Miller" wrote:
> 
> > >
> > > I'm considering writing a scripting language interface to FlightGear to
> > > experiment with script driven weather and aircraft failure events.  Is there
> > > a pointer to any documentation on interfacing with running flightgear on
> > > its http server?
> > >
> 
> > I'm implementing a similar idea except using the telnet interface
> > (--props=...) instead of http.  None of this stuff is in cvs yet.
> >
> > In answer to your question though, http requests are handled by the
> > HttpdChannel::foundTerminator() function in Network/httpd.cxx.
> 
> Ah of course.  I do have one question to whoever is implementing the
> telnet interface, though.  I can use it fine exactly once.  A second
> connection is accepted by fgfs, but does not respond to any commands.
> This makes debugging my code very difficult, as I have to restart
> flightgear each time.
> 

There was a bug in the network code that prevented subsequent
connections from getting through but I believe it is fixed in cvs.  The
current props/telnet server doesn't support multiple simultaneous
connections.  I have a fix in the pipeline but Curt has been busy.

FWIW I have written a python class that interfaces to the props server. 
It provides a dictionary-like interface to the property system.  For
example:

import FlightGear

# Establish a connection to the FlightGear props server
fg = FlightGear.FlightGear( "localhost", 5500 )

# Apply the parking brake
fg["/controls/parking-brake"] = 1

# Display the current heading
print fg["/orientation/heading-deg"]

# Display all toplevel properties
for prop in fg.ls():
  print prop

Cheers,
Bernie

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

Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Navaids fix.hxx,1.6,1.7ils.hxx,1.16,1.17 nav.hxx,1.22,1.23

[Bernie Bright]

Erik Hofman wrote:
> 
> David Megginson wrote:
> > Update of /var/cvs/FlightGear-0.7/FlightGear/src/Navaids
> > In directory seneca:/tmp/cvs-serv23071/src/Navaids
> >
> > Modified Files:
> >   fix.hxx ils.hxx nav.hxx
> > Log Message:
> > Mac OS X patches from Jonathan Polley.
> 
> > *** 37,41 
> >   #elif defined( SG_HAVE_NATIVE_SGI_COMPILERS )
> >   #  include 
> > ! #elif defined( __BORLANDC__ )
> >   #  include 
> >   #else
> > --- 37,41 
> >   #elif defined( SG_HAVE_NATIVE_SGI_COMPILERS )
> >   #  include 
> > ! #elif defined( __BORLANDC__ ) || (__APPLE__)
> >   #  include 
> >   #else
> 
> I think we should make more use of the STL_* header definitons in
> simgear/compiler.h
> 
> that would make these lines:
> 
> #include STL_IOSTREAM
> 

Here! Here!

Technically only  is needed but since a lot of older compilers
don't have it I can live with Erik's solution.  Another solution would
be to provide our own  that pulls in a suitable header.  Same
goes for other missing Std C++ headers.  It might help to reduce
preprocessor "noise".

Erik, I was thinking we could use Boost's compatability library I sent
you as a starting point.

Cheers,
Bernie

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

Re: [Flightgear-devel] Linux IDE

[Bernie Bright]

Christian Mayer wrote:
> 
> Hi,
> 
> 
> 
> as I'm now ready to run Linux frequently, I'm looking for a comfortable
> IDE for the development.
> 
> Has anyone exprience? Does KDevelop work nicely together with FGFS? Do I
> need to make spacial adjustmenst (on anyside)?
> 
> Oh, BTW, EMACS and VI/VIM are no option for me (vim is greqat to change
> a file, but not to have a overview over a big project)
> 
> CU,
> Christian
> 
There is an IDE project called anjuta at sourceforge.  The interface is
very Visual Studio-ish.  It is based on GTK/Gnome rather than KDE.  I've
only had a quick look at it but it seems fairly easy to use at its
current stage of development.

Bernie (dedicated emacs users)

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

Re: [Flightgear-devel] Latest Update Problems

[Bernie Bright]

Jonathan Polley wrote:
> 
> Two other things.  First there is a constant string in telnet.cxx that
> contains s, which MSVC does not like.  Second, telnet.cxx uses
> snprintf(), which is not supported under MSVC (for some reason, they use
> _snprintf(), go figure).
> 

Could we fix the snprintf/_snprintf problem once and for all by adding

#define snprintf _snprintf

to simgear/compiler.h in the MSVC section.

Bernie

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

Re: [Flightgear-devel] Latest MSVC Problem with options.cxx

[Bernie Bright]

"Curtis L. Olson" wrote:
> 
> Jonathan Polley writes:
> > MSVC does not like the size of the string constant in options.cxx
> >
> > C:\FlightGear\src\Main\options.cxx(1143) : error C2026: string too big,
> > trailing characters truncated
> > C:\FlightGear\src\Main\options.cxx(1181) : error C2026: string too big,
> > trailing characters truncated
> > C:\FlightGear\src\Main\options.cxx(1215) : error C2026: string too big,
> > trailing characters truncated
> 
> Bernie,
> 
> Maybe we need to chalk this up as a really nice idea that didn't quite
> work out as well as we hoped.  [Darned MSVC] :-) Who wants to do the
> honors of reverting back to the original code?
> 
I've reverted options.cxx to the previous version and am recompiling. 
Expect an update soon.

Bernie

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

Re: [Flightgear-devel] Latest Update Problems

[Bernie Bright]

Julian Foad wrote:
> 
> Jonathan Polley wrote:
> >
> > Two other things.  First there is a constant string in telnet.cxx that
> > contains s, which MSVC does not like.  Second, telnet.cxx uses
> > snprintf(), which is not supported under MSVC (for some reason, they use
> > _snprintf(), go figure).
> 
> I think the reason is that "snprintf" is not a standard (i.e. ANSO/ISO standard 
>library) function and a standard-conforming compiler should not introduce 
>non-standard names into the user's name space (names starting with _ are reserved for 
>this sort of purpose).
> 
> Anyway, I agree with Bernie's request that it should be #defined in the compiler.h.
> 

For the record snprintf() is part of the C99 standard.  Anyways I've
submitted a patch for Curt to commit.

Bernie

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

Re: [Flightgear-devel] the new telnet server and scripting

[Bernie Bright]

"Curtis L. Olson" wrote:
> 
> First, let me point out the new telnet server is *very* nice.  Bernie
> has rewritten it based on the plib net libs.  It can handle multiple
> concurrent connections.  This is a big improvement!

I'm not sure why you would need to run two or more sessions but there
you go.  The server design is based on Curt's httpd classes so I can't
take full credit.

> 
> Along with this, Bernie has also provided a demo python script that
> shows how you can use the telnet interface to remotely interact with
> and control a FlightGear application.  In the cvs source (run "cvs
> update -d" of course) look in $toplevel/scripts/python for the demo
> script.
> 
> So, to try this out run:
> 
> fgfs --telnet=5500
> python demo.py
> 
> Then watch the action.  This is a demo of functionality so you aren't
> going to see any earth shattering visual effects.  But, it's very cool
> from the geeky perspective of running an external script which has
> complete control over flightgear.

The python code is very experimental, really just proof of concept
stuff.  I was just toying around seeing how to use the props interface. 
I was thinking that this concept could be developed into a full blown
demostration for exhibitions.  A takeoff, circuit and landing, complete
with cut-aways to external views, zooms and pans, all under script
control would be really cool.

> 
> Bernie, on the subjects of building additional commands into the
> telnet interface, I agree with Melchior.  I'd rather not see the
> telnet interface being crammed with a bunch of extra commands that
> only the telnet interface knows about.  I haven't looked at this in a
> while, but the property manager should be able to manage "commands" as
> well as "values".  The command management is a bit of a hack (kind of
> but not really) but since we can tie variables to funtions (usually
> getters and setters) we can expose additional functionality through
> the property interface.
> 
> I think that would be the more appropriate way to do this and to
> develop additional commands.  This way, these commands will be
> available (and consistant) for any other interface mechanisms
> including joystick, keyboard, mouse in addition to remote scripts or
> web browsers, etc.
> 

I don't have a complete handle on the property system yet.  However if
we can do these sort of things through properties and/or the command
manager then that is definitely the way to go.

Cheers,
Bernie

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

Re: [Flightgear-devel] the new telnet server and scripting

[Bernie Bright]

"Curtis L. Olson" wrote:
> 
[snip]
> 
> Bernie, on the subjects of building additional commands into the
> telnet interface, I agree with Melchior.  I'd rather not see the
> telnet interface being crammed with a bunch of extra commands that
> only the telnet interface knows about.  I haven't looked at this in a
> while, but the property manager should be able to manage "commands" as
> well as "values".  The command management is a bit of a hack (kind of
> but not really) but since we can tie variables to funtions (usually
> getters and setters) we can expose additional functionality through
> the property interface.
> 
> I think that would be the more appropriate way to do this and to
> develop additional commands.  This way, these commands will be
> available (and consistant) for any other interface mechanisms
> including joystick, keyboard, mouse in addition to remote scripts or
> web browsers, etc.
> 

Bear with me while I get up to speed with the property system but I'm
just brainstorming...

Assuming we create some write-only properties that are tied to
commands.  Perhaps something like:

/command/view/next
/command/view/prev

Writing a value to /command/view/next switches to the next view.  Now
this functionality duplicates the view-cycle builtin command so I'm
wondering if should combine these two concepts?

Bernie

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

Re: [Flightgear-devel] Bad line endings when running on windows

[Bernie Bright]

Frederic Bouvier wrote:
> 
> The telnet interface produce wrong line ending when I run both FlightGear
> and the telnet client on Win2k. I've just sent a patch to Curt that produce
> line ending based on the platform where fgfs is running ( something between
> #ifdef and #endif ).
> 
> For the moment, this patch only address the issue when fgfs and
> the telnet client run on the same platform.
> 
> Thinking of it now, it would be better to generate proper line endings based
> on the capabilities of the client. Do the telnet interface support telnet
> commands DO, DONT, WILL and WONT ? or perhaps line ending can be deduced
> from
> the incoming command.
> 

Just a word of warning: there are currently two telnet servers in
FlightGear.  The original --props server and the new --telnet server.  I
haven't had time to combine them into a single server yet.  Neither
server implements telnet's option negotiation.  The fact that you can
connect to them with a telnet client doesn't make them telnet servers. 
You can connect to nntp, ftp, smtp and pop3 servers with a telnet client
too.  

As for line endings I think its simpler if we just use CRLF for both
client and server.  I will check that the new server always sends CRLF.

Cheers,
Bernie

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

[Flightgear-devel] easter egg!!

[Bernie Bright]

Wondered why the sudden increase in network traffic when starting
FlightGear just now.  Then heard the new intro theme.  Cute!  Very cute!

Bernie

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

Re: [Flightgear-devel] Re: Bad line endings when running on windows

[Bernie Bright]

Frederic Bouvier wrote:
> 
> From: "Melchior FRANZ" <[EMAIL PROTECTED]>
> > * Bernie Bright -- Sunday 19 May 2002 06:23:
> > > As for line endings I think its simpler if we just use CRLF for both
> > > client and server.  I will check that the new server always sends CRLF.
> >
> > ACK
> > Not that this is in any way obligatory, but the perl documentation says:
> >
> >   $ man perlipc|col -b|grep -A12 "Line Terminators"
> >  Internet Line Terminators
> >
> >  The Internet line terminator is "\015\012".  Under ASCII
> >  variants of Unix, that could usually be written as "\r\n",
> >  but under other systems, "\r\n" might at times be
> >  "\015\015\012", "\012\012\015", or something completely
> >  different.  The standards specify writing "\015\012" to be
> >  conformant (be strict in what you provide), but they also
> >  recommend accepting a lone "\012" on input (but be lenient
> >  in what you require).  We haven't always been very good
> >  about that in the code in this manpage, but unless you're
> >  on a Mac, you'll probably be ok.
> 
> This is off-topic. As Julian points out, RFC854, chapter 7, specify that
> a new line is CRLF in the telnet protocol.
> 
We are not bound to implement the telnet protocol because we don't
provide a telnet server.  However you are correct in that the props
server doesn't always respond with CRLF line terminators.  I have a
patch that I will send to Curt real soon.

Bernie

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

Re: [Flightgear-devel] Re: Telnet interface don't send proper line endings on windows

[Bernie Bright]

Frederic Bouvier wrote:
> 
> As we discussed in the list, line endings don't depends on the platform
> where the server or the client is run.
> 
> But the patch is imcomplete :
> 
> The help command is OK but the dump command still send only LF as line
> endings. In fact, my patch missed that point too. writeProperties is
> used to dump a node but the simgear version only produce LF.
> 
Hmmm.  I suppose writePropertes() could be modified to take a line
terminator argument that defaults to "\n".  On the other hand the dump
command produces valid xml as is.  As long as its readable by an xml
parser we shouldn't have to change anything.  Perhaps we should think of
dump as producing binary output thats not fit for human consumption.

Bernie

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

Re: [Flightgear-devel] Win32 Source code

[Bernie Bright]

A J wrote:
> 
> Hi all
> 
> Is there any flight gear source code for visual c++ 6.0
> 
> if there exist please send me its address
> 

FlightGear supports MSVC6.  Workspace and project files are included in
the source.  Visit the FlightGear web page at http://www.flightgear.org/
for download instructions.

Bernie

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

Re: [Flightgear-devel] Multiplayer Engine project started

[Bernie Bright]

On Mon, 24 Jun 2002 12:21:46 -0700
ace project <[EMAIL PROTECTED]> wrote:

[snip]

 The first important decision now is, do we
> multi-threading or multiplexing-IO ? For multiplexing,
> PLIB can be used. For multi-threading, we got a
> problem.
> Another issue is how to get the code to compile on
> other platforms, because threading and sockets aren't
> 100% portable, to say the least.

PLIB's socket library is reasonably portable.  It runs on every platform that  
FlightGear runs on.  There are many "portable" open source threading libraries  
available, Boost.Thread, ZThread and CommonC++ to mention just a few.

Bernie

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

Re: [Flightgear-devel] I have a Saitek Cyborg 3D Gold USB Stick

[Bernie Bright]

On Sun, 14 Jul 2002 07:33:46 -0400
David Megginson <[EMAIL PROTECTED]> wrote:

> Victoria Welch writes:
> 
>  > As for jscal, I am unable to locate it for mandrake.  The source I found
>  > (which seems to have been an early version ?!?!?!?!) wants to be
>  > compiled into the kernel and I find that just too odd.
> 
> I'm very surprised that this is not a standard part of Mandrake,
> because I've heard many people who like that distro.  If it's not,
> perhaps your life would be easier if you switched to another distro,
> because there must be many other things missing as well -- several
> FlightGear developers use Debian, which is beautifully simple to
> maintain and update but slightly harder to install than RedHat.  When
> you read about a new program and want to try it, it's usually as easy
> as
> 
>   apt-get install 

For whatever reason Mandrake doesn't include jscal or jstest.  However these are part 
of the joystick package which can be downloaded from your local cooker mirror.  
Alternatively you can download the linuxconsole package from sourceforge.  jscal and 
jstest are in the ruby/utils directory.

Cheers,
Bernie (a happy Mandrake 8.2 user)

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

Re: [Flightgear-devel] I have a Saitek Cyborg 3D Gold USB Stick

[Bernie Bright]

On 14 Jul 2002 09:02:50 -0700
Victoria Welch <[EMAIL PROTECTED]> wrote:

> Hi Tony,
> 
> Thanks for the response!
> 
> On Sun, 2002-07-14 at 08:39, Tony Peden wrote:
> > rpmfind lists this:
> > 
>http://www.rpmfind.net//linux/RPM/cooker/contrib/RPMS/joystick-1.2.15-1mdk.i586.html
> 
> Unfortunately Mandrake 8.2 comes with the 2.1.0 driver (where that
> exists, I have not a clue) and the 1.2.15 stuff will not run with the
> version I have .

Thats unfortunate.  I have successfully downloaded and compiled jscal from 
http://sourceforge.net/projects/linuxconsole/.  Of course the force feedback stuff I'm 
playing with doesn't want to work but you can't have everything.

Cheers,
Bernie

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

[Flightgear-devel] Bug in uiuc_menu.cpp

[Bernie Bright]

The function void d_1_to_1(double array1[100], double array2[100] ) passes an 
incorrect size to memcpy.  The correct value should be 100*sizeof(double) since 
sizeof(array2) is actually sizeof(double*).  Alternatively the size could be passed as 
a parameter effectively making d_1_to_1 a pointless wrapper around memcpy.

Cheers,
Bernie

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

Re: [Flightgear-devel] Removed simgear/interpreter/

[Bernie Bright]

On Wed, 18 Sep 2002 15:39:11 -0500
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:

> David Megginson writes:
> > I've updated configure.ac, but have not changed SimGear.dsp (an MSVC
> > thing?).  If someone who uses this file can send me a patched version,
> > I'll commit it ASAP.
> 
> The MSVC work spaces are generated automatically whenever I run "make
> dist".  I have taken care of this.
> 

I'm not sure if the am2dsp perl script will work any longer since we've changed to 
configure.ac.  Am2dsp is just automake modified to generate dsp and dsw files instead 
of Makefile.am.  If and when time allows I'll modify it to use the new regime.

Bernie

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

[Flightgear-devel] Loading static object problems.

[Bernie Bright]

I'm writing a plib loader for XPlane custom objects and have been testing it within 
FlightGear and have noticed a couple of problems.

Firstly, if the object is not found then fgLoad3DModel() throws an uncaught exception. 
 Adding a try/catch block to FGTileMgr::update() prevents FlightGear from exiting, see 
the attached diff.

Secondly, the texture path is set twice.  Once in FGTileMgr::update() and again in 
fgLoad3DModel().  The path set in fgLoad3DModel() is incorrect - it contains two 
instances of $FG_ROOT.  For the moment I've commented out this call to 
ssgTexturePath() but I'm not entirely sure if this correct in all cases.

Bernie




tilemgr.cxx.diff
Description: Binary data


model.cxx.diff
Description: Binary data

Re: [Flightgear-devel] Shared Scenery Objects

[Bernie Bright]

On Sun, 22 Sep 2002 07:53:34 -0400
David Megginson <[EMAIL PROTECTED]> wrote:

> For a while now, FlightGear has had support for adding static scenery
> objects (like buildings) to *.stg scenery files using the syntax
> 
>   OBJECT_STATIC 
> 
> The file is always loaded relative to the current scenery directory
> (such as /usr/local/scenery/w080n40/w077n45), which is great for
> one-off objects like the Golden Gate Bridge or the Empire State
> Building, but not so useful for objects like radio towers, barns,
> etc. that can be used over and over.
> 
> I have just added a new directive, OBJECT_SHARED, that works exactly
> like the above except that it loads the object relative to $FG_ROOT
> rather than the current scenery directory.  For example, I have my
> $FG_ROOT at /usr/local/FlightGear/ and my $FG_SCENERY at
> /usr/local/Scenery.  If I add this line to w080n40/w077n45/1696211.stg
> 
>   OBJECT_STATIC red-barn.ac -76.022499 45.319500 200 0
> 
> FlightGear will attempt to load
> 
>   /usr/local/Scenery/w080n40/w077n45/red-barn.ac
> 
> On the other hand, if I have
> 
>   OBJECT_SHARED Models/Buildings/red-barn.ac -76.022499 45.319500 200 0
> 
> FlightGear will attempt to load
> 
>   /usr/local/FlightGear/Models/Buildings/red-barn.ac
> 

Excellent!  Hopefully this will work for texture files referenced by the object.  FWIW 
I'm working on importing XPlane custom objects and many of them share textures.  I 
already have the SFO terminal and Golden Gate bridge loading.

> The big challenge right now is figuring out what tile to add an object
> to -- I will try to whip up a Perl script to help with this.  Once
> that's working, we can automatically add all NDB towers and VOR
> transmitters from our current data and populate the world a little
> more; one user has a copy of the FAA obstacle database, and that would
> allow us even more detail in the U.S.
> 

The following c++ program prints the tile name given a lat/lon.

[bbright@proton FlightGear-0.7]$ cat latlon.cxx 
#include 
#include 
#include 

using std::cout;

int
main( int argc, char* argv[] )
{
if (argc != 3)
{
cout << "Usage: " << argv[0] << "  \n";
return 1;
}

double dlat = atof( argv[1] );
double dlon = atof( argv[2] );

SGBucket b( dlon, dlat );

cout << b.gen_base_path() << "/" << b.gen_index_str() << "\n";

return 0;
}

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

Re: [Flightgear-devel] Shared Scenery Objects

[Bernie Bright]

On Sun, 22 Sep 2002 09:30:57 -0400
David Megginson <[EMAIL PROTECTED]> wrote:

> Bernie Bright writes:
> 
>  > FWIW I'm working on importing XPlane custom objects and many of
>  > them share textures.  I already have the SFO terminal and Golden
>  > Gate bridge loading.
> 
> Are those redistributable?
> 
They are freeware and may be redistributed as long as it is not for commercial 
purposes.  If we want to include them with FG (or as a separate download) then I will 
drop a line to the author.  But before that happens I should get the loader into plib.

Bernie

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

Re: [Flightgear-devel] Shared Scenery Objects

[Bernie Bright]

On Sun, 22 Sep 2002 11:00:18 -0400
David Megginson <[EMAIL PROTECTED]> wrote:

> It would be nice to set them up as a separate download, but we will
> need these in the base package soon, so unless the author is willing
> to change the terms, we'll have to reproduce them outselves.  I think
> that we need to add the Bay-area bridges before anything else; next
> could be a few obvious landmarks like the Cow Palace, the TransAmerica
> building, and Alcatraz, then the KSFO terminal buildings.
> 

The package I downloaded includes the following bridges:

ggbridge - Golden Gate
wobbridge
eobbridge
smbridge
srbridge
tnbridge
dunbridge

I'm not familiar with the names or positions of the Bay-area bridges but hopefully 
this includes them all.  The package contains terminals for Oakland and Seatac.  It 
also contains generic control towers, hangars, buildings, a prison and the space 
needle.

I will contact the author and see if he will allow us to repackage some of these 
objects and textures under a different, compatible, license.

Bernie

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

Re: [Flightgear-devel] Shared Scenery Objects

[Bernie Bright]

On Sun, 22 Sep 2002 11:54:00 -0400
David Megginson <[EMAIL PROTECTED]> wrote:

> I've checked a simple perl script into
> scripts/perl/scenery/calc-tile.pl in the FlightGear CVS.  It contains
> useful functions for calculating a tile path based on lon/lat and acts
> as a demo app.

I was wondering if it might be useful to include a c++ program too since most Windows 
programmers don't have perl.

Bernie

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

Re: [Flightgear-devel] MSVC 6.0 Problem with systems/vacuum/vacuum.cxx

[Bernie Bright]

On Mon, 23 Sep 2002 18:51:25 -0700
Jonathan Polley <[EMAIL PROTECTED]> wrote:

> MSVC does not have fmin() defined, so complains in vacuum.cxx.
> 

gcc 2.95.3 complains too.  fmin() is only defined if _ISOC99_SOURCE is defined before 
including .

Bernie

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

Re: [Flightgear-devel] MSVC 6.0 Problem with systems/vacuum/vacuum.cxx

[Bernie Bright]

On Tue, 24 Sep 2002 03:46:54 -0400
"Norman Vine" <[EMAIL PROTECTED]> wrote:

> Bernie Bright writes:
> 
> > On Mon, 23 Sep 2002 18:51:25 -0700
> > Jonathan Polley <[EMAIL PROTECTED]> wrote:
> >
> > > MSVC does not have fmin() defined, so complains in vacuum.cxx.
> > >
> >
> > gcc 2.95.3 complains too.  fmin() is only defined if _ISOC99_SOURCE is
> defined before including .
> 
> I wonder if we are going to need a sg_math.h
> if so here is a first stab at one
> 
[cut]

Well, as far as I can tell, fmin() is C99 not Std C++.  We could use std::min() but 
that causes a problem with MSVC where you have to use cpp_min() instead.  And so it 
goes on...

Bernie

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

Re: [Flightgear-devel] Startup seg fault

[Bernie Bright]

On Thu, 3 Oct 2002 20:52:54 -0700
"John Wojnaroski" <[EMAIL PROTECTED]> wrote:

> With the latest CVS for SimGear and FG (updated 20:00 PDT) seeing
> 
> Unable to detect the current language
> ./test: line 5 9148 Segmentation fault   yada yada yada
> 
> Wasn't paying attention to the discussions on internationalization -- did I
> miss something?
> 
> Base package was updated as of 03Oct02 02:01:31 EDT. Is CVS racing ahead of
> the base package?
> 

Had the same problem.  Updating the base package fixed it.

Bernie

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

Re: [Flightgear-devel] Startup seg fault

[Bernie Bright]

On Fri, 04 Oct 2002 01:51:32 -0400
John Check <[EMAIL PROTECTED]> wrote:

> On Thursday 03 October 2002 11:52 pm, John Wojnaroski wrote:
> > With the latest CVS for SimGear and FG (updated 20:00 PDT) seeing
> >
> > Unable to detect the current language
> > ./test: line 5 9148 Segmentation fault   yada yada yada
> >
> > Wasn't paying attention to the discussions on internationalization -- did
> > I miss something?
> >
> > Base package was updated as of 03Oct02 02:01:31 EDT. Is CVS racing ahead
> > of the base package?
> >
> > Regards
> > John W
> >
> 
> Not to my knowledge. 
> 
> I'm having a problem building Simgear myself
> 

I got a compilation error concerning cout and endl.  Commenting out the offending line 
fixed it.

Bernie

PS This is on Mandrake 9.0 with gcc3.2.

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

Re: [Flightgear-devel] STL and vectors

[Bernie Bright]

On Mon, 7 Oct 2002 07:36:53 -0400
David Megginson <[EMAIL PROTECTED]> wrote:

> Frederic Bouvier writes:
> 
>  > Or should it be :
>  > vector_of_elements.erase(&vector_of_elements[index]);
>  > 
>  > I think your are making the too rapid assumption that
>  > an iterator is a pointer to an element.
> 
> Don't iterators override the '+' operator if they're not just
> pointers?

Only random access iterators support the '+' operator.  Fortunately std::vector and 
std::deque provide just such iterators.

Bernie

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