RE: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Vivian Meazza wrote: So we have the situation where at least some of the current binary releases, do not follow this policy. The Windows for one seems to accept the crease token. Binary releases, by definition, are not meant to be rebuild, so the hassle of collecting patches and making all work is only supported by one volunteer, not the average user that want to compile from scratch. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Quoting Vivian Meazza : The patch has been committed to plib CVS. Now we only (...) need to convince them to release a new stable version. Excellent news, what about the joystick problem? not committed yet, but I just asked again on the plib list. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MSVC
Quoting Erik Hofman : RENNUIT Antoine 203220 Thésard wrote: Hello, I am new to flight gear. I am looking for a how to to compile FG under MSVC (either 6 or .net) : at the moment I am completely lost in all the libraries needed to link : how come these libraries (simgear, plib, zlib, metakit, openAL...) do not broadcast with simple .lib files??? I read several threads from the forum, but did not find enough information to go on. You can find MSVC (7.0) project files here: ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/ I've just made an update today with current project files for .NET 2003. Obviouly, path have to be changed. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] MSVC
It was my fault. The solution in FlightGear/cvs/FlightGear/FlightGear-2.sln is supposed to compile all you need for FlightGear. You just have to get software in the structure below : FlightGear/cvs/FlightGear = FlightGear FlightGear/cvs/SimGear= SimGear FlightGear/cvs/plib = plib FlightGear/zlib-1.1.4 = zlib pthread-snap-2004-06-22 = pthread for win32 The zip file reflect this structure. -Fred Quoting RENNUIT Antoine 203220 Thésard : Now it works, sorry for disturbing... -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de RENNUIT Antoine 203220 Thésard Envoyé : vendredi 3 décembre 2004 14:59 À : 'FlightGear developers discussions' Objet : RE: [Flightgear-devel] MSVC I cannot download the new file... -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Frederic Bouvier Envoyé : vendredi 3 décembre 2004 14:54 À : FlightGear developers discussions Objet : Re: [Flightgear-devel] MSVC Quoting Erik Hofman : RENNUIT Antoine 203220 Thésard wrote: Hello, I am new to flight gear. I am looking for a how to to compile FG under MSVC (either 6 or .net) : at the moment I am completely lost in all the libraries needed to link : how come these libraries (simgear, plib, zlib, metakit, openAL...) do not broadcast with simple .lib files??? I read several threads from the forum, but did not find enough information to go on. You can find MSVC (7.0) project files here: ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/ I've just made an update today with current project files for .NET 2003. Obviouly, path have to be changed. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New scenery build
Selon David Luff : Completely off topic, your screenshots look like you're getting dark lines at runway texture boundaries similar to what I see on an ATI machine, but not on a NVidia machine. Are you also on an ATI card, and am I correct in thinking that Andy Ross might have once produced a plib patch to cure this - does anyone know if it ever went into plib or not? I have them also with NVidia 5900FX. I think it is related with highest level of filtering. I am quite sure the problem lies in the genapt code but I hadn't time to investigate yet. There is something that seems strange though. This comment appears at line 93 of rwy_prec.cxx // we add 2' to the length for texture overlap. This puts the // lines on the texture back to the edge of the runway where they // belong. I wonder if that overlap is not the problem. As it does not show up with my GF3, I guess it doesn't appears on GF4 too so perhaps this why Curt is not seeing them ( otherwise he would surely have done something to cure them ). My rationale here is that it is likely to be in the code because otherwhise we would see them everywhere, not just on runways. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MSVC
RENNUIT Antoine 203220 Thésard a écrit : Hello, - you put flightgear, simgear, and plib sources into a cvs directory; so I guess we have to use the newest cvs version (I used tarball cvs version) of these packages. When I put the cvs version of flightGear sources in the project, VC tells me it cannot find dme.cxx, navcom.cxx, and radiostack.cxx. Actually these files are not in the cvs version of flightGear, but they are in the 0.9.6 version of the sources : what must I do? Delete the files from the project? Add dme.cxx, navcom.cxx, and radiostack.cxx, and there associated .hxx to my cvs files? - you added the following directory D:\Flight gear\FG-ProjectFiles-msvc71\FlightGear\cvs\plib\examples\src\ssg\majik. The project under VC tells me there should be 3 files called elevation_map.h, image_map.h, and magik_demo.cxx in this directory, unfortunately, you did not deliver them within the project files, do you know what's the problem? - I have the same problem with tux_example.cxx - the file jpegfactory.hxx needs to include jpeglib.h, and jerror.h, I cannot find anything about these files... I had a look on the web, I think it comes from a library, could you tell me more about that? How should it be installed to be used with FG project? Wow, that makes a lot of questions. I hope I am not too boring... Antoine. MSVC projects are not updated by core developers, so they are always lagging. You should consider CVS is the reference and delete instances in the project when files are deleted from CVS and add new ones that appears from time to time. You should remove the projects you don't want. tux_example, majik_demo and fgrun are additionnal programs that are not needed by flightgear. You should fine a copy of libjpeg ( search freshmeat ) for MSVC to compile jpegfactory.cxx, otherwise, remove that file because it is optionnally compiled under linux. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] MSVC
Selon RENNUIT Antoine 203220 Thésard [EMAIL PROTECTED]: That works better, but I still have several errors : - what is fadmin project useful for? The true question is can I remove it, because it needs FLTK, and it's a painful task to install it correctly (no .lib, no .dll...). fgadmin is a utility project and can be removed - I have a problem with the exit function declaration in stdlib.h, it tells me it is a redefinition, any idea? edit glut.h, locate exit and then change the file to have : #if _MSC_VER = 1200 _CRTIMP __declspec(noreturn) void __cdecl exit(int); #else _CRTIMP void __cdecl exit(int); #endif instead of : _CRTIMP void __cdecl exit(int); that works only for MSVC 6 -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] const and copy constructor
Jon Berndt wrote:
I have a situation where I am getting an error and I am not sure why. I have
a class
MyClass that has a copy constructor. The class has a private member that is a
const
pointer (the pointer is constant - not what the pointer points to):
class MyClass {
public:
MyClass(const MyClass mc); // copy constructor
private:
AnotherClass* const ptrToAnotherClass;
}
The copy constructor needs to copy the const element ptrToAnotherClass to be
complete. I
do it like this:
MyClass::MyClass(const MyClass mc) :
ptrToAnotherClass(mc.ptrToAnotherClass)
{
// other assignments
}
This gives me an odd error:
non-static const member `AnotherClass* const ptrToAnotherClass', can't use
default
assignment operator
If I remove the const specifier from the declaration for ptrToAnotherClass,
and then move
the assignment at the copy constructor into the code (instead of doing the
const thing
in the initializer list), then the compile works.
Any suggestions?
I think it complains the class has no constructor other than the copy one.
you should try to add one :
class MyClass {
public:
MyClass(AnotherClass *p); // constructor
MyClass(const MyClass mc); // copy constructor
private:
AnotherClass* const ptrToAnotherClass;
}
MyClass::MyClass(AnotherClass *p) :
ptrToAnotherClass(p)
{
// other assignments
}
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next release planning ...
Curtis L. Olson wrote : ... but right now I would tentatively be targeting somewhere between Christmas and New Years. I will not be able to make win32 binaries until 2005. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Mac OS X Application Bundle Available
Arthur Wiebe wrote : I couldn't get fgrun to compile on OSX and so have started to write one that's OS X native using Cocoa and AppleScript. (Applescript Studio) You should try to share your experience / problems with fgrun in order to get help. I can check your patches if you have some. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Mac OS X Application Bundle Available
As far as I know, there is no fgrun list, so post here.
it looks like your implementation of termios.h is incomplete.
try changing the line :
term.c_oflag = ~( OLCUC | ONLCR );
by
term.c_oflag = ~ONLCR;
-Fred
Arthur Wiebe wrote :
Should I post it here or in the fgrun mailing list? I assume here
since there's only one person subscribed to the fgrun list.
I was getting this error:
if g++ -DHAVE_CONFIG_H -I. -I. -I. -I/FlightGear/include -g -O2 -MT
run_posix.o -MD -MP -MF .deps/run_posix.Tpo \
-c -o run_posix.o `test -f 'run_posix.cxx' || echo './'`run_posix.cxx; \
then mv -f .deps/run_posix.Tpo .deps/run_posix.Po; \
else rm -f .deps/run_posix.Tpo; exit 1; \
fi
run_posix.cxx: In member function `void Wizard::run_fgfs()':
run_posix.cxx:61: error: `OLCUC' undeclared (first use this function)
run_posix.cxx:61: error: (Each undeclared identifier is reported only once for
each function it appears in.)
make[2]: *** [run_posix.o] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
I looked the relevant code which is this:
void
Wizard::run_fgfs()
{
pid_t pid;
int master = -1;
#if defined(HAVE_TERMIOS_H)
struct termios term;
tcgetattr( STDOUT_FILENO, term );
term.c_oflag = ~( OLCUC | ONLCR ); // This is the error line,
something with the OLCUC constant
pid = pty_fork( master, 0, term, 0 );
#else
pid = pty_fork( master, 0, 0, 0 );
#endif
And I program in PHP and some other, this is just a little too
different for me to figure out how to fix.
On Sat, 18 Dec 2004 14:34:02 +0100, Frederic Bouvier [EMAIL PROTECTED] wrote:
Arthur Wiebe wrote :
I couldn't get fgrun to compile on OSX and so have started to write
one that's OS X native using Cocoa and AppleScript. (Applescript
Studio)
You should try to share your experience / problems with fgrun in order
to get help. I can check your patches if you have some.
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Mac OS X Application Bundle Available
Arthur Wiebe a écrit :
I must say that fgrun looks like a lot of bad coding to me. After
doing what you said that file compiled but then I got this error:
Making all in src
make all-am
if g++ -DHAVE_CONFIG_H -I. -I. -I. -I/FlightGear/include -g -O2 -MT
fgrun_pty.o -MD -MP -MF .deps/fgrun_pty.Tpo \
-c -o fgrun_pty.o `test -f 'fgrun_pty.cxx' || echo './'`fgrun_pty.cxx; \
then mv -f .deps/fgrun_pty.Tpo .deps/fgrun_pty.Po; \
else rm -f .deps/fgrun_pty.Tpo; exit 1; \
fi
In file included from fgrun_pty.cxx:32:
/usr/include/utmp.h:75: error: 'time_t' is used as a type, but is not defined
as a type.
fgrun_pty.cxx: In function `int tty_login(int)':
fgrun_pty.cxx:138: error: `login_tty' undeclared (first use this function)
fgrun_pty.cxx:138: error: (Each undeclared identifier is reported only once for
each function it appears in.)
make[2]: *** [fgrun_pty.o] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
The funny thing is that this is the problem code:
/**
*
*/
int
tty_login( int fd )
{
#if defined(HAVE_LOGIN_TTY)
//return login_tty( fd ); And commented this out
return tty_login( fd ); // I added this
I am not sure you want an infinite recursion here ;-) You should try to
find the real login_tty or undefine HAVE_LOGIN_TTY.
http://www.die.net/doc/linux/man/man3/login_tty.3.html
again, your unix emulation is broken if you don't have it. fgrun is
behaving correctly under linux.
#else
I just commented out where it calls the login_tty method and replaced
it with the method name switched around.
Looks like a simple coding mistake to me there. So then that part
compiled but I now I get this error:
Making all in src
make all-am
if g++ -DHAVE_CONFIG_H -I. -I. -I. -I/FlightGear/include -g -O2 -MT
fgrun_pty.o -MD -MP -MF .deps/fgrun_pty.Tpo \
-c -o fgrun_pty.o `test -f 'fgrun_pty.cxx' || echo './'`fgrun_pty.cxx; \
then mv -f .deps/fgrun_pty.Tpo .deps/fgrun_pty.Po; \
else rm -f .deps/fgrun_pty.Tpo; exit 1; \
fi
In file included from fgrun_pty.cxx:32:
/usr/include/utmp.h:75: error: 'time_t' is used as a type, but is not defined
as a type.
make[2]: *** [fgrun_pty.o] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
A quick look in utmp.h and I see time_t defined there like this:
struct lastlog {
time_t ll_time;
charll_line[UT_LINESIZE];
charll_host[UT_HOSTSIZE];
};
But it doesn't look like time_t is even used in fgrun_pty.cxx so I
commented out the include.
I don't think that should have been done though.
After that, it all build but exits with the following:
Be warned that it's rather long:
g++ -g -O2 -L/FlightGear/lib -o fgrun wizard.o wizard_funcs.o
advanced.o advanced_funcs.o AirportBrowser.o AirportTable.o Fl_Table.o
Fl_Table_Row.o Fl_Plib.o Fl_Heading_Dial.o main.o io.o fgfsrc.o
logwin.o settings.o util.o run_posix.o fgrun_pty.o -lsgprops -lsgxml
-lsgmisc -lsgstructure -lsgdebug -lplibssg -lplibsg -lplibul -lfltk
-lm -lz
You should begin to fix the configure script before all other thing. At
least, the link command is missing -lfltkgl and -lgl that are the OpenGL
related librairies. The other missing symbols seems to be Apple C
runtime. There must be an additional, Apple specific, library to add at
link time.
-Fred
ld: Undefined symbols:
Fl_Gl_Window::make_current()
Fl_Gl_Window::draw_overlay()
Fl_Gl_Window::hide()
Fl_Gl_Window::init()
Fl_Gl_Window::show()
Fl_Gl_Window::flush()
Fl_Gl_Window::resize(int, int, int, int)
Fl_Gl_Window::~Fl_Gl_Window()
vtable for Fl_Gl_Window
_glBlendFunc
_glClear
_glClearColor
_glDepthFunc
_glEnable
_glLoadIdentity
_glMatrixMode
_glPopMatrix
_glPushMatrix
_glShadeModel
_glViewport
_CGLGetCurrentContext
_glDisable
_glGetIntegerv
_glLightf
_glLightfv
_glMultMatrixf
_glClipPlane
_glFrustum
_glLoadMatrixf
_glOrtho
_glPolygonOffset
_glGetTexLevelParameteriv
_glPixelStorei
_glTexImage2D
_glBindTexture
_glDeleteTextures
_glGenTextures
_glTexEnvi
_glTexParameteri
_glArrayElement
_glBegin
_glColor4f
_glColor4fv
_glColorPointer
_glDisableClientState
_glDrawArrays
_glDrawElements
_glEnableClientState
_glEnd
_glLineWidth
_glLoadName
_glNormal3fv
_glNormalPointer
_glPolygonMode
_glPopAttrib
_glPopClientAttrib
_glPopName
_glPushAttrib
_glPushClientAttrib
_glPushName
_glTexCoordPointer
_glVertexPointer
_glCallList
_glVertex3fv
_glAlphaFunc
_glColorMaterial
_glMaterialf
_glMaterialfv
_glTexCoord2fv
_glDeleteLists
_glEndList
_glGenLists
_glNewList
_glTranslatef
_FSRefMakePath
_FSpMakeFSRef
_FindFolder
_CopyMask
_GetPortBitMapForCopyBits
_GetWindowPort
_RGBBackColor
_RGBForeColor
_CopyBits
_DisposeGWorld
_GetGWorld
_GetGWorldPixMap
_GetPort
_GetPortBounds
_GetWindowFromPort
_LockPixels
_NewGWorld
_QDIsPortBuffered
_SetGWorld
_UnlockPixels
_UpdateGWorld
_SysBeep
_DisposeRgn
_DisposeWindow
_NewRgn
_QDFlushPortBuffer
_SetRectRgn
_ShowWindow
_UnionRgn
_AECountItems
_AECreateDesc
_AEDisposeDesc
_AEGetNthPtr
_AEGetParamDesc
_AEInstallEventHandler
_AERemoveEventHandler
_AppendResMenu
Re: [Flightgear-devel] FlightGear Mac OS X Application Bundle Available
Arthur Wiebe wrote : if g++ -DHAVE_CONFIG_H -I. -I. -I. -I/FlightGear/include -g -O2 -MT fgrun_pty.o -MD -MP -MF .deps/fgrun_pty.Tpo \ -c -o fgrun_pty.o `test -f 'fgrun_pty.cxx' || echo './'`fgrun_pty.cxx; \ then mv -f .deps/fgrun_pty.Tpo .deps/fgrun_pty.Po; \ else rm -f .deps/fgrun_pty.Tpo; exit 1; \ fi In file included from fgrun_pty.cxx:32: /usr/include/utmp.h:75: error: 'time_t' is used as a type, but is not defined as a type. make[2]: *** [fgrun_pty.o] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1 A quick look in utmp.h and I see time_t defined there like this: time_t is defined in time.h . If utmp.h doesn't include it already, add this line *before* utmp.h : #include time.h -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgLoadAircraft
Paul Surgeon a écrit : What is the status of fgLoadAircraft in aircraft.cxx? Was it ever actually used and if so what was it's functional state? At the moment it's just dead code - it's not called from anywhere. As far as I understand the source, it is bound to the load-aircraft command. So I guess that it is intended to be called from an xml file, presumably a menu or a dialog. Maybe Erik can elaborate because CVS annotate reports his name in front of the function : http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/src/Aircraft/aircraft.cxx?annotate=1.12cvsroot=FlightGear-0.9 The comment of rev 1.2 is : A first stab at an aircraft selection dialog -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: CVS error msg
John Wojnaroski a écrit : Curtis L. Olson wrote: John Wojnaroski wrote: Hi Curtis, When you have a moment. I may have sent this to you yesterday from one of my other machines, but can't find a copy. If a dup, my apologies. In file included from ../../src/Cockpit/panel.hxx:50, from ../../src/Cockpit/cockpit.hxx:36, from main.cxx:61: ../../src/Input/input.hxx: In method `const class SGPropertyNode * FGBinding::getArg()': ../../src/Input/input.hxx:123: warning: choosing `SGPropertyNode_ptr::operator SGPropertyNode *()' over `SGPropertyNode_ptr::operator const SGPropertyNode *() const' ../../src/Input/input.hxx:123: warning: for conversion from `SGPropertyNode_ptr' to `const SGPropertyNode *' ../../src/Input/input.hxx:123: warning: because conversion sequence for the argument is better main.cxx: In function `bool fgMainInit(int, char **)': main.cxx:759: assuming on overloaded member function make[2]: *** [main.o] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 Kind of lost on this one... Kind of lost on this one too ... I think this might be Andy Ross's code so he might be a good one to ask. What compiler version are you using? Curt. Running 2.95.4... Andy, if you're listening, any ideas. If this is due to using an older compiler, should there be a test in to check for that? I tried the patch below with MSVC and it also compiles without any problem, so if it works with gcc 3.x and other compilers, I am to apply it. -Fred RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v retrieving revision 1.190 diff -u -r1.190 main.cxx --- main.cxx16 Dec 2004 13:19:01 -1.190 +++ main.cxx20 Dec 2004 07:55:10 - @@ -754,9 +754,9 @@ _bootstrap_OSInit++; #endif -fgRegisterWindowResizeHandler( FGRenderer::resize ); -fgRegisterIdleHandler( fgIdleFunction ); -fgRegisterDrawHandler( FGRenderer::update ); +fgRegisterWindowResizeHandler( FGRenderer::resize ); +fgRegisterIdleHandler( fgIdleFunction ); +fgRegisterDrawHandler( FGRenderer::update ); #ifdef FG_ENABLE_MULTIPASS_CLOUDS bool get_stencil_buffer = true; ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiling with Visual Studio 2003.net
Andy messier wrote : Hey All, Are there step-by-step instructions on how to build the FlightGear source using Visual Studio? I've been fighting with this build all weekend, and am getting nowhere. I finally got all of the libraries and headers in the right places, and now it returns thousands of invalid external symbol errors. Are the Microsoft build files in there legit, or is this just someone's wishful thinking? It has been discussed very recently : http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32470 -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiling with Visual Studio 2003.net
Frederic Bouvier a écrit : Andy messier wrote : Hey All, Are there step-by-step instructions on how to build the FlightGear source using Visual Studio? I've been fighting with this build all weekend, and am getting nowhere. I finally got all of the libraries and headers in the right places, and now it returns thousands of invalid external symbol errors. Are the Microsoft build files in there legit, or is this just someone's wishful thinking? It has been discussed very recently : http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32470 see also : http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32556 http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32570 http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32600 -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiling with Visual Studio 2003.net
Andy messier wrote : Ok, I downloaded FG-ProjectFiles-msvc71 (I have version 7.1). Now, when I download the FlightGear source, should I REPLACE the FG-ProjectFiles-msvc71\FlightGear\cvs\FlightGear directory with the source, or put the source inside this directory? Same with SimGear and plib? I can't find any instructions among those project files. I would be you, I wouldn't overwrite the files I've just downloaded, but I guess you would not find the project files in the official distribution, so it is really up to you. Also, which file should I open in VisualStudio to build the source? Sorry for the basic questions...I'm new to Visual Studio. You should read this one : http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/032478.html -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiling with Visual Studio 2003.net
Drew a écrit : I haven't overwritten any files...I'm just trying to understand what goes where. I have a directory structure called FG-ProjectFiles-msvc71, which does not contain the FlightGear source. I have another directory, which I downloaded separately, called Flightgear-0.9.6. Where do I put it? Should I have a directory as follows? FG-ProjectFiles-msvc71\FlightGear\cvs\FlightGear\FlightGear-0.9.6 my layout is (I have a drive named I: ) : I:\FlightGear\cvs\FlightGear I:\FlightGear\cvs\FlightGear\src I:\FlightGear\cvs\FlightGear\src\Main ... The path of the files located in the project files should have helped you. Or do I need to do something different? There are no instructions. FlightGear/cvs/FlightGear = FlightGear isn't explicit to me. the directory 'cvs' could imply that the projects are for the cvs version. If you want to use them for the 0.9.6 version, you would have to adapt it because few files were added, other removed and some moved. The file to load is the solution file, named FlightGear-2.sln, .vcproj files are the project files and hold path to source files and compile options. They are xml files. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiling with Visual Studio 2003.net
Drew wrote : I'm getting the following errors (most of them several times) Cannot open include files: FL/Fl.h FL/Fl_File_Chooser.h FLTK 1.1.x, only needed to build fgadmin. Remove the project from the solution if you don't want to build it GL/glut.h GLUT, mandatory plib/ssg.h sg.h PLIB, mandatory Cannot open source files: .\majik_demo.cxx PLIB demo, optional .\simgear\scene\sky\clouds3d\camdisplay.cpp .\src\AIModel\AICarrier.cxx .\src\AIModel\submodel.cxx .\src\Cockpit\hud_rwy.cxx .\src\Fdm\groundcache.cxx .\src\fdm\sp\ACMS.cxx .\src\fdm\sp\ADA.cxx .\src\Instrumentation\encoder.cxx .\src\Instrumentation\kr_87.cxx .\src\Instrumentation\kt_70.cxx .\src\Instrumentation\marker_beacon.cxx .\src\Instrumentation\navradio.cxx .\src\Instrumentation\transponder.cxx .\src\Network\ATC-Inputs.cxx New, CVS only, ( or wait 0.9.8 ), files - remove them from the solution if you really want to compile 0.9.6 .\ssgLoadASC.cxx .\ssgSaveIV.cxx CVS plib files. same as above .\tux_example.cxx Plib demo, optional There are a bunch of warnings as well, but I won't worry about them yet. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Compiling with Visual Studio 2003.net
Thanks Antoine, This could be the README I never manage to write. On remark : the pthreads-snap-something can be the latest ( advised ). It is just that it requires a name change in the project files. -Fred Quoting RENNUIT Antoine : There cannot exist a howto to compile these sources, because it depends on the cvs sources, and cvs files are always changing. Anyway, I did compile the whole project under msvc.net 2003 (both under win XP, and win 2k), 2 weeks ago, and I can testify that it works well, here are a few guidelines : - download glut for windows from http://www.xmission.com/~nate/glut.html, and unzip it - copy glut.h to %VISUAL_DOT_NET_2003_DIRECTORY%\Vc7\PlatformSDK\Include\GL - copy glut32.dll to %WINDOWS_DIRECTORY\System32 - download the openAL sdk for windows at http://developer.creative.com/landing.asp?cat=1sbcat=31top=38, and install it. - create a directory AL in %VISUAL_DOT_NET_2003_DIRECTORY%\Vc7\PlatformSDK\Include\, copy the files you find in %OPENAL_DIRECTORY%\Include into this new directory, then you should find 8 files (al.h, alc.h, alctypes.h, altypes.h, alu.h, alut.h, aluttypes.h, and alutypes.h) in %VISUAL_DOT_NET_2003_DIRECTORY%\Vc7\PlatformSDK\Include\AL - copy the dll files you find in %OPENAL_DIRECTORY%\dll in %WINDOWS_DIRECTORY\System32 (there are 2 files : OpenAL32.dll, and wrap_oal.dll) - download the file FG-ProjectFiles-msvc71.zip at ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/ (careful, this file only works under msvc.net 2003, not 2002), unzip it - download the version of pThread for windows indicated in the FG-ProjectFiles-msvc71 newly created directory (should be pthreads-snap-2004-06-22, so you must not download the latest version but an older one) at http://sources.redhat.com/pthreads-win32/, unzip it. In explorer, drag the newly created directory pthreads-snap-2004-06-22, and drop it on the directory FG-ProjectFiles-msvc71\pthreads-snap-2004-06-22 (pressing Ctrl key at the same time to copy the files, its safer than just to move them). - copy pthreadVCd.dll (that you can now find in FG-ProjectFiles-msvc71\pthreads-snap-2004-06-22), in %WINDOWS_DIRECTORY\System32 - download the cvs version (tarballs are ok) of flightgear, plib, and simgear at (http://www.flightgear.org/Downloads/source.html, http://plib.sourceforge.net/download.html, and http://www.simgear.org/downloads.html), unzip them (you can use 7-zip, http://www.7-zip.org/, to unzip .tgz, or .tar.gz files). - drag, and drop (copying them, it's safer...) these 3 newly created directories onto there respective counterpart in FG-ProjectFiles-msvc71\FlightGear\cvs - unzip zlib-1.1.4.tar.gz that you find in FG-ProjectFiles-msvc71\FlightGear\cvs\SimGear\src-libs, and drag and drop this new zlib-1.1.4 directory to FG-ProjectFiles-msvc71\FlightGear\zlib-1.1.4 Now we have to modify the project, and the code itself, because several things changed since FG-ProjectFiles-msvc71.zip was made : - open the solution named FlightGear-2.sln in FG-ProjectFiles-msvc71\FlightGear\cvs\FlightGear - find the files dme.cxx, dme.hxx, navcom.cxx, navcom.hxx, radiostack.cxx, radiostack.hxx in project FlightGear, directory Lib_Cockpit in solutions explorer UNDER MSVC, and delete them from the project : they do not exist anymore in the latest cvs versions of FlightGear find flightgear.ico, and flightgear.rc in project FlightGear, in solutions explorer UNDER MSVC, and delete them from the project - find the files jpgfactory.cxx, and jpgfactory.hxx in project SimGear, directory Lib_sgscreen in solutions explorer UNDER MSVC, and delete them from the project - add the file ssgAnimTransform.cxx to project ssg in solutions explorer UNDER MSVC - delete the projects magik_demo, tux_examples, fgadmin, and fgrun from the solution - open glut.h that you find in %VISUAL_DOT_NET_2003_DIRECTORY%\Vc7\PlatformSDK\Include\GL, find _CRTIMP void __cdecl exit(int);, and replace it with #if _MSC_VER = 1200 _CRTIMP __declspec(noreturn) void __cdecl exit(int); #else _CRTIMP void __cdecl exit(int); #endif Hope it helps... Antoine. PS : mail me back if you think something is strange... -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Andy messier Envoyé : lundi 20 décembre 2004 20:01 À : Flightgear-devel@flightgear.org Objet : [Flightgear-devel] Compiling with Visual Studio 2003.net Hey All, Are there step-by-step instructions on how to build the FlightGear source using Visual Studio? I've been fighting with this build all weekend, and am getting nowhere. I finally got all of the libraries and headers in the right places, and now it returns thousands of invalid external
Re: [Flightgear-devel] Compiling with Visual Studio 2003.net
Drew wrote : Hey Guys, First, I want to thank you guys for all of your help. You've been very patient with me, since I'm really clueless as to how to get this working for the first time...I just want to make sure I get this compiled right to begin with (and with a stable release), so I avoid compounding existing problems with my own changes, and have trouble tracking down their cause. Anyway, I *think* I'm getting closer. Here are the errors I'm getting now. error C2381: 'exit' : redefinition; __decllspec(noreturn) differs fatal error C1083: Cannot open include file: 'jpeglib.h': No such file or directory That first error is in stdlib.h, which seems a bit bothersome. The second error is in jpgfactory.hxx, and is and #include jpeglib.h. Is there a standard C++ library I'm missing? This one is listed in Antoine's message, and you should find it in the archive : - open glut.h that you find in %VISUAL_DOT_NET_2003_DIRECTORY%\Vc7\PlatformSDK\Include\GL, find _CRTIMP void __cdecl exit(int);, and replace it with #if _MSC_VER = 1200 _CRTIMP __declspec(noreturn) void __cdecl exit(int); #else _CRTIMP void __cdecl exit(int); #endif -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiling with Visual Studio 2003.net
You either have to get libjpeg or remove the file that needs it. http://freshmeat.net/projects/libjpeg/ -Fred Drew wrote : That fixed the __dcllspec problem, but it's still not seeing jpeglib.h. And I tried commenting out this include line, and it couldn't find error.h, either...both of which are supposed to be standard C includes. Am I still missing a set of libraries? Thanks again, Drew On Tue, 21 Dec 2004 21:12:20 +0100, Frederic Bouvier [EMAIL PROTECTED] wrote: Drew wrote : Hey Guys, First, I want to thank you guys for all of your help. You've been very patient with me, since I'm really clueless as to how to get this working for the first time...I just want to make sure I get this compiled right to begin with (and with a stable release), so I avoid compounding existing problems with my own changes, and have trouble tracking down their cause. Anyway, I *think* I'm getting closer. Here are the errors I'm getting now. error C2381: 'exit' : redefinition; __decllspec(noreturn) differs fatal error C1083: Cannot open include file: 'jpeglib.h': No such file or directory That first error is in stdlib.h, which seems a bit bothersome. The second error is in jpgfactory.hxx, and is and #include jpeglib.h. Is there a standard C++ library I'm missing? This one is listed in Antoine's message, and you should find it in the archive : - open glut.h that you find in %VISUAL_DOT_NET_2003_DIRECTORY%\Vc7\PlatformSDK\Include\GL, find _CRTIMP void __cdecl exit(int);, and replace it with #if _MSC_VER = 1200 _CRTIMP __declspec(noreturn) void __cdecl exit(int); #else _CRTIMP void __cdecl exit(int); #endif ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Development Platform Help Needed
Quoting Christian Mayer: Chuck Cole schrieb: I unfortunately do not have an FTP server or the like to make my version of the source code available to you. But since you have some time, I could simply e-mail you the source code that I have built along with some simple setup instructions. Collectively, the source code for all of the projects is rather large; however, I believe that they could be split up sufficiently enough to be e-mailed. We can take the details of setting up any arrangement off-list. My sparetime isn't that much, that I could build and test FGFS in it :( I was asking just for a documention how you set up MSVC++ so that it compiles FGFS. That would be a nice HOWTO for other developers (we get a request for that every few months) There was the beginning of one posted last month : http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/032959.html It is for MSVC .NET 2003 ( aka 7.1 ) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DHC2F see-through panel issue solved
Jim Wilson wrote: The basic problem with the ac file is that model's data sets were being defined with both vertices and kids. Unfortunately I don't think the ac3d file spec itself explicitly says that a given obj data set must be a Group _or_ an Object but not both. But that is the way the AC3D program works, and that is why the editor was behaving so badly. This is a lesson for Blender users : Objects can be grouped together by being child of an Blender's 'Empty' entity but Objects shouldn't be made parent of other objects. 'Empty's can be stacked into a hierarchy ( Empty parent of Empty's ). -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] May I help with scenery?
Roberto Inzerillo wrote: I would like to help, maybe with some simple objects around the scenery (buildings, aerial pictures of the terrain, some more details for the two airports around my city, Palermo, that's just an example). Probably just some pictures won't help _that_ much (although I'm convinced there is still interest in the raw images) the results you might produce from these images are very much appreciated. The infrasctucture for creating a central repository for scenery objects (database and different front-ends) is currently in the works. Please let me know about the repository. Anyway, is there an easy way to identify a building position in order to put the 3D model in the correct place (lat/long/alt) into the F.G. world scenery? Should I consider buying a portable GPS, going in place and check what the machine says? Is there a way I could use aerial/staellite pictures (there are tons on the net and many are free for viewing) and extract position spots out of them in order to correctly orientate and position the 3D obejct (here I'm mainly talking about buildings). Any suggestion? FGSD ( http://fgsd.sf.net ) can help you to place buildings using a scanned map or an aerial photography. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] fgrun and fgfsrc
I just commit a change in fgrun CVS that use command line options to start fgfs. That means that user preferences ( ~/.fgfsrc on linux, system.fgfsrc on Windows ) are not overwritten anymore. Regards, -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Scenery download
The graphical interface and the FTP interface links for scenery download are still pointing to Scenery-0.9.5 This is in page http://www.flightgear.org/Downloads/scenery.html Regards, -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Problem with Beaver and sound
I just discovered that FG is suggesting me to upgrade my sound driver after alGenSources failed :-( This is the first time and all the other aircraft I tried never did the same. I even remember flying successfully with it not far ago. A quick glance with the debugger showed me that alGenSources failed the 33rd time it was called, so I guess my driver/hardware ( yes a realtek on brand new mainboard with brand new drivers ) is only able to cope with 32 sources. I also noticed that 20 sources are allocated for the same sample : Aircraft/dhc2/Sound/click.wav Question: is it normal that the same sample is being allocated multiple times ? Couldn't we use a reference counter and share the same buffer/source ? It seems that click.wav is bound to panel switches. I guess that a panel will lots of switches will saturate the sound driver just like too much texture will flood the graphic card. Regards, -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Little flaws with Win32 package
Martin Spott a écrit : Hello, I just downloaded the Win32 package and took it for a test-ride. There are three things I'd like to mention: 1.) The Isle of Alcatraz doesn't look as I'm used to it from FlightGear. To my knowledge Frederic adapted the terrain to include the heliport, this is now missing. Heliport are no longer in the new Scenery ( 0.9.8 ) 2.) On Windows I usually place e system.fgfsrc file in the 'data/' directory. This usually works fine but there is a flaw that already was present in the 0.9.6 Win32 binary: The --aircraft=-flag is not being honoured, I always get the c172. Everything else looks good. System.fgfsrc is no longer overwritten but it is still read by flightgear. So you can get old value you don't want anymore -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Little flaws with Win32 package
Martin Spott wrote : System.fgfsrc is no longer overwritten but it is still read by flightgear. This is what I meant: I run FlightGear and it actually reads most of the values in my manually written 'system.fgfsrc', except a single one (as far as I can tell), which is the aircraft to use. I've already moved the --aircraft=-clause to different positions but this didn't make any difference. From the beginning, fgrun was starting fgfs with 2 command line options : --fg-root and --aircraft because you need the first to find system.fgfsrc and the second because it was not used in this file. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Little flaws with Win32 package
Quoting Martin Spott : Frederic Bouvier wrote: Martin Spott wrote : This is what I meant: I run FlightGear and it actually reads most of the values in my manually written 'system.fgfsrc', except a single one (as far as I can tell), which is the aircraft to use. I've already moved the --aircraft=-clause to different positions but this didn't make any difference. From the beginning, fgrun was starting fgfs with 2 command line options : --fg-root and --aircraft because you need the first to find system.fgfsrc and the second because it was not used in this file. I never talked about 'fgrun', I am talking about FlightGear itself, alias 'fgfs.exe'. How do I manage to let FlightGear on Windows read the aircraft name from the 'system.fgfsrc' ? Is the use of 'system.fgfsrc' still a 'supported' option with FlightGear on Windows ? If yes, then I think FlightGear on Windows simply has a bug because it ignores the aircraft name. If not, is there an official replacement for this configuration file ? I was just writting about my experience on the problem, and this is not a recent issue, although I silently worked around. But are you sure it is specific to windows ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.8, Mac OS X build
Quoting Martin Spott: Christian Brunschen wrote: Or to put is more succinctly: when I downloaded FlightGear and got an unwelcome religious pamphlet thrown in my face, I got a seriously bad taste in my mouth. Indeed, in my opinion the FlightGear community can't tolerate such action, I am just shocked that I could be associated with this. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] v1.0 musings
Oliver C. wrote FlightGear has gone a long way, but imo it is still far too early for a 1.0 production release. Hey, there is a life after 1.0. Why not 1.1, 2.0 etc... Trying to reach the perfection the first shot is the best way to drag our 0.x forever that make feel that FG is still in beta and unusable for the mass. People will be happy to see FG progressing beyond 1.0 and will wait new versions with more expectations. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.8, Mac OS X build
Paul Surgeon a écrit : Whether you want to remove the file or not is your choice but just consider for a moment that a lot of people have put work into FG and they don't necessarily share the same beliefs. You may possibly be offending them by re-distributing their hard work with your beliefs. If I was a *radical* Muslim I would probably come and burn your house down. ;-) And the *radical* christian will ... you already know the story. It lasts for thousands years now. Very good argument Paul. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] aircraft required to start
Stewart Andreason a écrit : It seems this aircraft is required to start FlightGear. fgfs WARNING: ssgLoadAC: Failed to open '/usr/local/share/FlightGear/data/Aircraft/pa28-161/Models/pa28-161.ac' for reading Abort This plane is required by the AI/ATC module and has been removed from the standard distribution. It is available on the website though. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] fgrun improvements
To bring fgrun to 1.0 quality grade, and after receiving suggestions from Curt, I am now planning to add basic options to the wizard instead of keeping them hidden behind the Advanced button. Maybe by reducing the size of the command line textfield ( it could also be move to the Advanced section ). For the moment, my shortlist for basic options is : --geometry ( with a combo box of standard resolutions ) --time-of-day --(en/dis)able-game-mode --(en/dis)able-random-objects --(en/dis)able-ai-models --(en/dis)able-auto-coordination --(en/dis)able-real-weather-fetch --(en/dis)able-horizon-effect --(en/dis)able-enhanced-lighting --(en/dis)able-specular-highlight and optionally --atlas ( with default options ) --3d-clouds ( perhaps. they are not finished but are sometimes gorgeous ) --multiplayer I also want to have better resizing to have a more professional look. Also it would be nice to be able to fetch and install aircraft and scenery directly from the master server ( a add new button that connect via http ). Maybe it would require that the script that generate the aircraft download page also generate an XML file that could be remotely parsed to ease aircraft selection. Comments welcome Regards, -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cessna 172 problem in 9.8
Quoting Erik Hofman : Innis Cunningham wrote: Seeing this is probably the first aircraft a new user will try what a great advert.A panel that is upside down in the middle of the night with no engines running and no obvious way of getting them started. I mean if the idea is to discourage people from using FG I could not think of a better way. Reading all the other threads currently runing talking about making FG user friendly and the new version has this.At least the 737 works maybe it should be the default aircraft and then when people have mastered it they can move onto something more difficult like the 172. You seem to neglect the fact that there are certain special purpose models around that are not designed for use by the average user but that is very useful for what it's designed for. But this is an advanced feature that is proposed to average users, and near the top of the list in fgrun. So dependencies really needs to be sorted out to be able to remove that option from the default package. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Quoting Martin Spott : Frederic Bouvier wrote: Comments welcome Great ideas, just one little concern: What measures are applied to identify which airports should show up in the selection list ? Consider a user has installed most of the world scenery, is FGrun then going to parse the whole scenery to see which airports are present ? I don't think so, because it will take too much time. To my impression FGrun looks at the base scenery directories and decides which airports lie in the present scenery areas (according to the airport database). Now what about those airports that are present in the airport database but not part of the senery - as all those helipads that, as you told, are now excluded from the scenery ? When I tried the 0.9.8 Win32 package I chose Alcatraz from the list in FGrun and noticed, that the field is actually not present in the scenery - this could be fixed, I forgot this one. It is not an improvement though, rather a fix ;-) The scenery scan is done every time and is very long although it is threaded and doesn't prevent you to launch flightgear. Curt suggested to show all the content of apt.dat.gz and check the availability afterward. I am now thinking to check only against the first level of directories to see if they lie in an existing 10x10 chunk ( eventually with special case for the 2 1x1 chunks of the base package ). And rely more on the refresh button already present than a systematic scan. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Quoting Erik Hofman: Frederic Bouvier wrote: I forgot this one. It is not an improvement though, rather a fix ;-) The scenery scan is done every time and is very long although it is threaded and doesn't prevent you to launch flightgear. Curt suggested to show all the content of apt.dat.gz and check the availability afterward. I am now thinking to check only against the first level of directories to see if they lie in an existing 10x10 chunk ( eventually with special case for the 2 1x1 chunks of the base package ). And rely more on the refresh button already present than a systematic scan. Now that we use apt.dat (X-Plane format) it would be possible to walk the list and get the lat/lon of the aircraft (first two parameters of the runway definition if I'm not mistaken). This allows you to search in for the proper directory right away instead of checking every airport in every directory. As scenery are packed by chunked of 10x10 degrees, it seems useless to check deeper inside the scenery tree. And at least we could start at heliport locations that are in apt.dat but not in the scenery. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft loading problem in 9.8
Quoting Innis Cunningham: Curtis L. Olson writes Innis, I had no problem loading the version Ampere sent me in v0.9.8. I did notice there was a large (and seemingly arbitrary) mix of file permission, capitalization, etc. I'm running linux. If you are running windows, perhaps there is a dos/unix line ending problem in one of the files? Thanks Curt and yes I am runing windows. But if there was a line ending problem would this have not showed up in 9.6 and 9.5.In these versions it runs without trouble. The ac loader has been overhauled and many features were added, and regressions or stricter checked could have sneak in. Send me privately this model if you want me to test on the windows platform with adequate debugging tools. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Jim Wilson wrote : Norman Vine said: but I don't see where setting the lat less then the ground elevation has any bearing on this this sounds more like a parsing error Norman Well, yeah, fgrun still needs to be fixed. The fix is in CVS -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems building from CVS
Andrew Midosn a écrit : I've just updated my source code from CVS, but the build fails with the following: Update SimGear too. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems building from CVS
Andrew Midosn a écrit : --- Frederic Bouvier [EMAIL PROTECTED] wrote: Update SimGear too. Yup - my poor tired brain eventually noticed that it was complaining about SimGear *not* FlightGear (doh!), so I've updated that also. I'm still getting errors relating to FGMetar, so it certainly looks as if something's broken there. I'll keep digging. You configure'd --with-thread or --without-thread ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems building from CVS
Andrew Midosn a écrit : I've just updated my source code from CVS, but the build fails with the following: It looks as though the methods getRain(), getHail() and getSnow() rely on private attributes that haven't been declared. They are declared line 237-239 of simgear/environment/metar.hxx and are protected. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FGMetar.cxx
Andrew Midosn a écrit : I've fixed one problem with the FGMetar constructor, where the call to the parent class SGMetar was incorrect, but now have another problem. In the constructor the method getCAVOK() is called, although it isn't defined anywhere in either FlightGear or SimGear. Unfortunately I have no idea what this function is supposed to do. I'll try defining it as a bool in FGMetar that just returns True for the moment, but that isn't really a solution. getCAVOK is at line 208 of simgear/environment/metar.hxx I would really like to sort this out and feel I am contributing in a small way to the project, but I'm not sure enough of what this code is trying to do. Sorry. You really have screwed your SimGear tree, if you think it is up to date. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG GUI toolkits
Paul Surgeon a écrit : Can someone comment on how FLTK works under OpenGL? Would it be possible to use FLTK and all it's nice widgets in FG and drop the rather crude PUI toolkit? fgrun and fgsd are here to prove OpenGL is possible with FLTK. You also can have a look at GLgooey : http://glgooey.sourceforge.net/ -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] How to convert from WGS84 coordinates?
Robicd wrote: Hi, I've made a .ase 3d object (a Villa of my town) for a scenery. I have a satellite picture of the place where the Villa resides, which has datum wgs84 coordinates of the two corners of the bitmap. I really don't know how to convert such coordinates (1st corner is 353620.2/4225543.6, 2nd corner is 354212.2/4225976.1) to a format suitable for a .stg file. Where should I look at for docs? The online ones where not very clear to me :-( Any help? fgsd can help you for that task. http://fgsd.sf.net -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Frederic Bouvier a écrit : To bring fgrun to 1.0 quality grade, and after receiving suggestions from Curt, I am now planning to add basic options to the wizard instead of keeping them hidden behind the Advanced button. Maybe by reducing the size of the command line textfield ( it could also be move to the Advanced section ). For the moment, my shortlist for basic options is : --geometry ( with a combo box of standard resolutions ) --time-of-day --(en/dis)able-game-mode --(en/dis)able-random-objects --(en/dis)able-ai-models --(en/dis)able-auto-coordination --(en/dis)able-real-weather-fetch --(en/dis)able-horizon-effect --(en/dis)able-enhanced-lighting --(en/dis)able-specular-highlight and optionally --atlas ( with default options ) --3d-clouds ( perhaps. they are not finished but are sometimes gorgeous ) --multiplayer I also want to have better resizing to have a more professional look. This is in CVS now ( should show up in a few hours on SF ). In the meantime, a screenshot : http://frbouvi.free.fr/flightsim/fgrun-basic.jpg Also it would be nice to be able to fetch and install aircraft and scenery directly from the master server ( a add new button that connect via http ). Maybe it would require that the script that generate the aircraft download page also generate an XML file that could be remotely parsed to ease aircraft selection. The airport list refresh fix and the message when launching fgfs are the next step -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Erik Hofman wrote : Frederic Bouvier wrote: This is in CVS now ( should show up in a few hours on SF ). In the meantime, a screenshot : http://frbouvi.free.fr/flightsim/fgrun-basic.jpg If you're going this path (and it certainly does look good) then you might want to consider removing the command-line textbox altogether. It might look a bit daunting for a new user. Is there another path ? At least people are able to see immediately the result of their actions as the text is refresh in realtime. I can also consider putting the text box in the Advanced section -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Model animation
Jon Stockill a écrit : I've recently produced a model of a wind turbine, which I'm in the process of adding to the scenery, but when they're clustered together in groups it looks rather unnatural as they're all spinning round in perfect synchronisation. Is it possible to introduce some random offset to make things look a little bit more natural? If so, how? I did something for the radio towers. they don't blink at unisson. I introduced the use-personality tag but this is done only for the timed animation. What animation do you want to have personality ? spin, rotation ? this must be implemented in animation.cxx -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Vivian Meazza wrote : Fred wrote Erik Hofman wrote : Frederic Bouvier wrote: This is in CVS now ( should show up in a few hours on SF ). In the meantime, a screenshot : http://frbouvi.free.fr/flightsim/fgrun-basic.jpg If you're going this path (and it certainly does look good) then you might want to consider removing the command-line textbox altogether. It might look a bit daunting for a new user. Is there another path ? At least people are able to see immediately the result of their actions as the text is refresh in realtime. I can also consider putting the text box in the Advanced section I'd go with the Advanced section - that's a common practice elsewhere. I implemented something in between : http://frbouvi.free.fr/flightsim/fgrun-basic-2.jpg The popup on this window is modal and stay as long as FG is running : http://frbouvi.free.fr/flightsim/fgrun-basic-3.jpg -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Erik Hofman a écrit : Frederic Bouvier wrote: I implemented something in between : http://frbouvi.free.fr/flightsim/fgrun-basic-2.jpg The popup on this window is modal and stay as long as FG is running : http://frbouvi.free.fr/flightsim/fgrun-basic-3.jpg Much better, great work! If someone want to try : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgrun-win32-20050123.zip -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Vivian Meazza wrote : Fred wrote: Erik Hofman a écrit : Frederic Bouvier wrote: I implemented something in between : http://frbouvi.free.fr/flightsim/fgrun-basic-2.jpg The popup on this window is modal and stay as long as FG is running : http://frbouvi.free.fr/flightsim/fgrun-basic-3.jpg Much better, great work! If someone want to try : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgrun-win32-20050123.zip Works nicely. However, the advanced options repeat some of the ordinary options, I suppose this is a legacy of earlier software: illogical though. I can't see any great value in the show command line option, since this is adequately covered (or should be) by the Advanced options. When the Show See Advanced as the reference : all options should be there. And you already noted : it's legacy. Command Line options are displayed, I felt that you were inviting these to be edited direct, indeed that would be nice. This is also a critism of the 'Advanced Options' - some of them aren't - e.g. Airport, Aircraft. I would think that options should be just that, and items should only be displayed where they can be changed. I want to have the resulting command line somewhere so I can copy/paste to ask support, or debug from the shell. And parsing the command line could be added in the future but it is at the bottom of my priority list. Finally, it would perhaps be better English to say: 'FlightGear has been started' or 'FlightGear starting' noted Good progress, and so quick too, Thanks, -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Model animation
Quoting Ampere K. Hardraade [EMAIL PROTECTED]: On January 23, 2005 10:38 pm, Jorge Van Hemelryck wrote: On Mon, 24 Jan 2005 00:39:36 +0100 Frederic Bouvier wrote: Soon on your screen : http://frbouvi.free.fr/flightsim/fg-spin-perso.jpg Has this screenshot been taken near Perpignan, by any chance ? If so, they're among the best flying landmarks I know... Very nice... I think this is the mountain that you see at 1 o'clock while you are on 28R at KSFO. I hacked the radio towers and you see the group that is on top of San Bruno mountain near KSFO. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Model animation
Quoting Dave Martin : On Sunday 23 Jan 2005 23:39, Frederic Bouvier wrote: Jon Stockill a écrit : Frederic Bouvier wrote: If you look at the tower-medium.xml, you will have an idea on how it is made. Jon, I will see if I can do something during the week for the spin animation. Soon on your screen : http://frbouvi.free.fr/flightsim/fg-spin-perso.jpg Brilliant :-) Self destructing radio masts no less (they cut their own guy ropes) ;-) Any insight into the method you used for the randomisation? C++ hack into the animation code. The initial problem is that the same model is spread on the scenery without copying the data. So every instance shares the same set of animation parameters. I modified the load_model procedure in modellib.cxx ( already in CVS ) to add a new plib branch object that hold personality data. It is a set of C++ map that use the pointer of the unique personality branch to store animation state variables. For reference, look at personality.[ch]xx. You can already see it in action and in the code for the SGTimedAnimation. I now have to build a patch to add this behavior to the SGSpinAnimation. I also have to update documentation. Basically, in the spin animation, you'll replace : factor2.0/factor starting-pos-deg0/starting-pos-deg by : factor random min1.8/min max2.2/max /random /factor starting-pos-deg random min0/min max360/max /random /starting-pos-deg again, look at tower-medium.xml for an example in situation. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Model animation
I wrote: I also have to update documentation. Basically, in the spin animation, you'll replace : factor2.0/factor starting-pos-deg0/starting-pos-deg by : factor random min1.8/min max2.2/max /random /factor starting-pos-deg random min0/min max360/max /random /starting-pos-deg I forgot that you'll also have to add : use-personality type=booltrue/use-personality -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AirportList
Quoting Andrew Midosn: OK, I appear to have the Select Airport from List option working properly (as far as I can tell). I'm not completely happy with the solution, as I have had to declare a constant for PUCLASS_LIST that could be reassigned within plib. I have used a value at the top end of the scale to try to reduce the risk, but it is still possible that this could be broken by changes to plib. I'll include the diffs here in case this is worth using, or in case anyone would like to offer any advice or suggestions. Hi Andrew, Thanks for your efforts. I just have practical remarks regarding patch post to the list. Use unidiff ( -u ) because all those are confusing mail readers that interpret added lines as message quote Attach the file because many lines are split Better yet, send directly to one maintainer with CVS write access This way you will avoid the frustration of having your patch ignored just because it is unusable without a man-month worth of effort to rebuild something that could be understood by the patch utility. Regards, -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AirportList
Quoting Andrew Midosn: --- Frederic Bouvier [EMAIL PROTECTED] wrote: Thanks for your efforts. I just have practical remarks regarding patch post to the list. Use unidiff ( -u ) because all those are confusing mail readers that interpret added lines as message quote Attach the file because many lines are split Better yet, send directly to one maintainer with CVS write access This way you will avoid the frustration of having your patch ignored just because it is unusable without a man-month worth of effort to rebuild something that could be understood by the patch utility. Thanks for the advice. I'll try and sort that out when I get back from work. Who would be the best person to send the diffs to? It depends of the patch. Curt and Erik have full access ( with DavidM but he is offline for several weeks ). Some specific modules have their own maintainer with write access restricted to the directory they manage ( Andy for yasim, DaveL for ATC, Jim can access the base package ). You can have a look at flightgear-cvslog for a track of who is doing what. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: --aircraft=ufo in system.fgfsrc is ignored
Quoting Geoff Air: It certainly paves the way for fgrun to simply write the system.fgfsrc, and run the binary with a minimum of command line parameters ... and leaves a persistent file 'trace' of what fgrun 'requested' of FG ... more info benefit ... Because some argued, and I mostly agree, that fgrun shouldn't overwrite user's preferences, command line options are now used. This is why I want to keep the command line textbox : people can see what's going on and can provide these informations when asking for support. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: --aircraft=ufo in system.fgfsrc is ignored
Martin Spott wrote: Frederic Bouvier wrote: Quoting Geoff Air: It certainly paves the way for fgrun to simply write the system.fgfsrc, and run the binary with a minimum of command line parameters ... and leaves a persistent file 'trace' of what fgrun 'requested' of FG ... more info benefit ... Because some argued, and I mostly agree, that fgrun shouldn't overwrite user's preferences, command line options are now used. Nevertheless the proposed make much sense for those who don't use FGrun but configure FlightGear using the system.fgfsrc instead. I was not arguing against the patch but reacting to the idea that fgrun should overwrite system.fgfsrc or any user file. But... The fact that Geoff tells that the file is read twice ring a little bell in my mind. I think the issue was raised sometimes ago and could have unwanted side effects I can't recollect for the moment. A search in the mailing list archives maybe will enlight us more. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: --aircraft=ufo in system.fgfsrc is ignored
Quoting Martin Spott: Frederic Bouvier wrote: But... The fact that Geoff tells that the file is read twice ring a little bell in my mind. I think the issue was raised sometimes ago and could have unwanted side effects I can't recollect for the moment. It makes sense - especially in the context of the claim, that $HOME/.fgfsrc on Unix a read more than once as well. See, as nice as the XML configuration system is, it _must_ bring such a 'feature' to the developer. In order to figure which command line paramters you are allowed to use you have first to determine $FG_ROOT. If $FG_ROOT is defined by the $HOME/.fgfsrc alias 'system.fgfsrc', then you have to red that file first, look for $FG_ROOT, read the necessary details and then reread the config file in order to figure which of the details is being triggered in the config. There's nothing abnormal with such a procedure. Well, it might be cleaner to create an array to store the parameters that you read from the config file and later do multiple reads on this array but the basic approach is the same, I was not clear. Reading the file twice is not a problem. Loading an aircraft twice might be. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] Airports
Quoting Paul Surgeon: On Wednesday, 26 January 2005 17:44, Curtis L. Olson wrote: Fred is pondering/working on a more optimal solution for the next release. There are a number of good ideas he can try so I'm sure he'll come up with something that works quite well. :-) Does fgrun scan the scenery directories everytime it is run?! Yes, and I hope to fix that soon. Still pondering. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] How to convert from WGS84 coordinates?
Quoting Robicd : Datum: WGS84 Projection: NUTM33 Coordinate top left x: 353620.2 y: 4225543.6 Coordinate bottom right x: 354212.2 y: 4225976.1 These are UTM North Zone 33 I entered these coordinates in fgsd and I had my test picture mirrored upside down. It appears that your bottom has a northings (y) value greater than your top. Anyway, I get these ( decimal ) values : x: 353620.2 y: 4225543.6 = lat: 38.16592 lon: 13.32904 x: 354212.2 y: 4225976.1 = lat: 38.16991 lon: 13.33570 HTH -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Alcatraz
Quoting Dave Martin: On Friday 28 Jan 2005 16:01, Curtis L. Olson wrote: With help from Thomas Markowitz, I have posted a side by side comparison of the FlightGear Alcatraz model versus a real photo here: http://www.flightgear.org/Gallery/ Good work Frederic! Regards, Curt. It really cuts the mustard. Was the terrain at Alcatraz designed 'by hand' or is it the regular terrain data? This is the smallest photo scenery we have ;-) It is a blender model that was made after a topo map and an aerial photo from terraserver-usa. The buildings are after google image search. I removed the flat land area that was in the scenery with fgsd. The real photo can be seen here : http://www.nps.gov/alcatraz/ -Fred BTW Curt, it is Alcatraz, not AlcRatraz (R emphazized) in the legend of the images in the Gallery. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Secondary display - game mode
Quoting Curtis L. Olson : Drew wrote: I'm not sure what SDL means, but it will run on the primary display without the secondary one going black, so I don't think what you said is true...at least in my case. I'm using the latest stable version of flightgear, which I compiled myself from the source using VisualC++. So I can make changes to the code if necessary. Drew, My experience is that SDL works fine on a multiheaded system (two video cards) if you are running in default window-dressing mode. If you try to go full screen, (at least on Linux) then the other windows are locked out. It may behave better on windows, or maybe newer versions of SDL behave better (???) Just reporting my experience on linux, fullscreen, w/ 2 video cards (not a single multiheaded video card) ... For me, this caused a big problem because I wanted to run an instructor station on the 2nd head (but it was totally locked out with full screen SDL.) If Drew uses my project files, then GLUT is linked and used, not SDL. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.115, 1.116
Erik Hofman wrote :
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
In directory baron:/tmp/cvs-serv24714
Modified Files:
fg_init.cxx
Log Message:
Geoff Air:
RE: --aircraft=ufo in system.fgfsrc is ignored
To change a 'feature', one that has been mentioned here many
times, and again recently, place the following code block
into fgInitFGAircraft.
In its favour, I would argue this means FG can be run without
a command line, provided FG_ROOT has been set in the
environment, and that seems to me, as it should be ... ;=))
Perhaps the only counter, is that system.fgfsrc is read twice,
but so are others, like .fgfsrc, for other (local) options ...
or system.fgfsrc should .nt. be used for 'aircraft' ?
Well, reading this piece of code, I don't see how it could work. see below :
Index: fg_init.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/fg_init.cxx,v
retrieving revision 1.115
retrieving revision 1.116
diff -C2 -r1.115 -r1.116
*** fg_init.cxx 27 Dec 2004 17:35:22 - 1.115
--- fg_init.cxx 29 Jan 2005 10:22:44 - 1.116
***
*** 344,347
--- 344,353
if ( !aircraft.empty() ) {
Aircraft not empty here, otherwise the test had failed
SG_LOG(SG_INPUT, SG_INFO, aircraft = aircraft );
This shouldn't change the aircraft variable
+ if ( aircraft.empty() ) {
useless test because aircraft is not empty ( see above )
+ // Check for $fg_root/system.fgfsrc
+ SGPath sysconf( globals-get_fg_root() );
+ sysconf.append( system.fgfsrc );
+ aircraft = fgScanForOption( --aircraft=, sysconf.str() );
+ }
So the block above is never executed This is dead code.
fgSetString(/sim/aircraft, aircraft.c_str() );
} else {
-Fred
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for emissive animation for instruments (ver 2)
Erik Hofman wrote : Jim Wilson wrote: not part of cvs logtext Note the diff file has been renamed from the earlier submission. This version works better with more complex models. /not part of cvs logtext This patch adds support to the model animation system for modifying emissive states on the fly so that it is possible to make lights appear to dimm. It's committed. Thanks. I have to figure out how you did this, the alpha-blend patch seemed to be broken at the moment, probably because of a change in plib :-/ Or because of display lists. We did a trick a the time. Something to disallow the use of display lists for some animations -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for emissive animationfor instruments (ver 2)
Vivian Meazza wrote : Fred wrote Erik Hofman wrote : Jim Wilson wrote: not part of cvs logtext Note the diff file has been renamed from the earlier submission. This version works better with more complex models. /not part of cvs logtext This patch adds support to the model animation system for modifying emissive states on the fly so that it is possible to make lights appear to dimm. It's committed. Thanks. I have to figure out how you did this, the alpha-blend patch seemed to be broken at the moment, probably because of a change in plib :-/ Or because of display lists. We did a trick a the time. Something to disallow the use of display lists for some animations If my memory serves correctly, it went wrong at about that time. It would be good to get it back. AFAICS, it is still there with the ufo. Could you check by putting fgfs in chase view and do some actions on the throttle. Where should I look to see something wrong ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.115, 1.116
Erik Hofman wrote : Frederic Bouvier wrote: I can revert the patch or someone running windows should provide me a patch instead. Or do both, because the current patch seems useless. Is it windows specific ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.115, 1.116
Frederic Bouvier a écrit :
Erik Hofman wrote :
Frederic Bouvier wrote:
I can revert the patch or someone running windows should provide me a
patch instead.
Or do both, because the current patch seems useless.
Is it windows specific ?
This one seems better ( move the added block 3 lines upward ) :
cvs -z4 -q diff -u fg_init.cxx (in directory
I:\FlightGear\cvs\FlightGear\src\Main\)
Index: fg_init.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/fg_init.cxx,v
retrieving revision 1.116
diff -u -r1.116 fg_init.cxx
--- fg_init.cxx29 Jan 2005 10:22:44 -1.116
+++ fg_init.cxx29 Jan 2005 12:56:47 -
@@ -340,15 +340,15 @@
}
}
+if ( aircraft.empty() ) {
+// Check for $fg_root/system.fgfsrc
+SGPath sysconf( globals-get_fg_root() );
+sysconf.append( system.fgfsrc );
+aircraft = fgScanForOption( --aircraft=, sysconf.str() );
+}
// if an aircraft was specified, set the property name
if ( !aircraft.empty() ) {
SG_LOG(SG_INPUT, SG_INFO, aircraft = aircraft );
-if ( aircraft.empty() ) {
-// Check for $fg_root/system.fgfsrc
-SGPath sysconf( globals-get_fg_root() );
-sysconf.append( system.fgfsrc );
-aircraft = fgScanForOption( --aircraft=, sysconf.str() );
-}
fgSetString(/sim/aircraft, aircraft.c_str() );
} else {
SG_LOG(SG_INPUT, SG_INFO, No user specified aircraft, using
default );
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for emissive animationfor instruments (ver 2)
Vivian Meazza a écrit : Fred wrote Erik Hofman wrote : Jim Wilson wrote: not part of cvs logtext Note the diff file has been renamed from the earlier submission. This version works better with more complex models. /not part of cvs logtext This patch adds support to the model animation system for modifying emissive states on the fly so that it is possible to make lights appear to dimm. It's committed. Thanks. I have to figure out how you did this, the alpha-blend patch seemed to be broken at the moment, probably because of a change in plib :-/ Or because of display lists. We did a trick a the time. Something to disallow the use of display lists for some animations If my memory serves correctly, it went wrong at about that time. It would be good to get it back. The reflector has the same appearance with or without the use of display lists. Could it be a property name problem instead ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas release candidate
Robicd wrote : A windows binary of the code a few weeks ago is here: ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/atlas-win32-20050112.zip courtesy of Fred Bouvier. Hopefully he will produce a release binary as well. Oh! That's nice :-) Thank you Frederic, you are sooo great ! Downloaded right now ... I needed to dowload GLUT win32 binaries too before getting Atlas to run. Then I had to copy the Atlas files into a \atlas subdiretory under c:\programmi\flightgear\data\ and write some command line options to atlas.exe ... anyway, it works, I will play around with it tonite :-) There is a new set with headless support for Windows as well as for Unix : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/atlas-win32-20050129.zip It works for me with --size= up to 4096 -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Andy Ross a écrit : Christian Mayer wrote: Manual Massing wrote: Yes, textures and geometry are paged and decompressed asynchronously in the background (seperate thread). The engine supports image compression to save IO (and possibly bus) bandwith, e.g. JPEG and S3TC compression. The first maybe quite taxing on the CPU, so we usually only use JPEG for the finest detail level textures, which account for most of the data, and S3TC for the lower detail levels. Do you know: http://www.sjbaker.org/steve/omniv/jpegs_are_evil_too.html Honestly, Steve is just wrong on this one. Lossy compression works just fine in moderation. The S3TC format itself is a lossy algorithm that is inferior in quality to JPEG in basically every conceivable way, and it's supported navtively by the texture hardware for goodness sake. Yes, using JPEG as an intermediate format during content creation is a dumb idea due to progressive data loss. Refusing to use it for final/shipping textures based on this advice is just dumb. Real-world 3D applications and games ship their images compressed with lossy algorithms. Has anyone actually looked at how much of the base package is taken up by SGI+ format image files? (Which have absolutely abysmal compression ratios, but that's a different argument.) I wrote a quick script at one point to recursively convert all these to default-quality JPEGs, and the savings was staggering. Something like a 75% reduction. It is still true that JPEG have no alpha channel, so not all textures could be converted. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for emissive animation for instruments (ver 2)
Jim Wilson wrote : Erik Hofman said: Jim Wilson wrote: not part of cvs logtext Note the diff file has been renamed from the earlier submission. This version works better with more complex models. /not part of cvs logtext This patch adds support to the model animation system for modifying emissive states on the fly so that it is possible to make lights appear to dimm. It's committed. Thanks. I have to figure out how you did this, the alpha-blend patch seemed to be broken at the moment, probably because of a change in plib :-/ Hah. That's funny, I didn't even notice that code and it does almost the same thing. I'll fix the alpha-blend and send a patch...unless you've already gotten it. The exact same code with the GL_DIFFUSE instead of GL_EMISSION, with a couple other minor changes should work. Note that the material states are often shared by different branches so it is important to clone the one(s) you want to modify. Jim, You should have a look at the constructor of your new animation. There are 2 unused local variables that have the same name than 2 members that should be initialized with 0. Something like the code below. -Fred cvs -z4 -q diff -u simgear\scene\model\animation.cxx (in directory I:\FlightGear\cvs\SimGear\) Index: simgear/scene/model/animation.cxx === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/scene/model/animation.cxx,v retrieving revision 1.29 diff -u -r1.29 animation.cxx --- simgear/scene/model/animation.cxx29 Jan 2005 10:31:25 -1.29 +++ simgear/scene/model/animation.cxx29 Jan 2005 19:27:12 - @@ -1123,8 +1123,8 @@ _color1 = props-getFloatValue(emiss-green, 0.0); _color2 = props-getFloatValue(emiss-blue, 0.0); _old_brightness = 0; - ssgSimpleState* _cached_material; - ssgSimpleState* _cloned_material; + _cached_material = 0; + _cloned_material = 0; } SGEmissionAnimation::~SGEmissionAnimation () ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for emissive animation for instruments (ver 2)
Erik Hofman a écrit : Jim Wilson wrote: Uggh...sometimes plib really sucks. The ssg API seems pretty straight forward until some quirk rears its ugly head. There's just enough documentation to make you think it'll work. The above idea didn't pan out. It seems odd that I can write a GL_EMISSIVE state and it gets rendered next time, but the GL_DIFFUSE state update seems to have no effect. Anyone know why? There has been a hack to get alpha blending to work when display lists are activated. Maybe this is having the opposite effect at this time? You can disable that be commenting out the line ignore = true; for theSGBlendAnimation in simgear/scene/model/model.cxx It's just a ild guess though. This hack is working right for the ufo. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for emissiveanimationfor instruments (ver 2)
Jim Wilson a écrit : Note that earlier in this thread it was mentioned that the hack that's in SimGear now worked with plib 1.8.3 and does not work with plib 1.8.4 (I've confirmed). Someone also mentioned that the hack is working on one particular model, but I haven't looked at that yet. Really I just want to un-hackify this thing so that it uses the plib API. The question is, should I be able to do so with the current API? (in principle that is, assuming no bugs, alpha-sort issues, etc.) Jim, there is no black magic behind this hack that is not one. We found when implementing display lists, that we couldn't manipulate state anymore. So, for certain animation, we just returned back to immediate rendering. There is a 'ignore' flag ( sgMakeAnimation function ) in model.cxx that is doing just that. When a Blend animation is detected, the makeDList function is not called for the animation branch. It is just valid plib usage. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fun with the FAA DOF.
Chris Metzler a écrit : With building positions and heights from the FAA Digital Obstruction File, and a few new buriable (thus, height-adjustable) models, here's an approach into La Guardia Rwy 04, starting over Staten Island. http://www.speakeasy.org/~cmetzler/KLGA_04_approach_001.jpg thru http://www.speakeasy.org/~cmetzler/KLGA_04_approach_023.jpg Some highlights: lower manhattan and downtown brooklyn start to come into view -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_003.jpg lower manhattan and downtown brooklyn start to come into view -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_003.jpg over downtown brooklyn, show detail on some of the models -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_010.jpg view of midtown manhattan -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_011.jpg adjusting to final with manhattan in background -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_015.jpg over the tarmac, manhattan in the distance -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_021.jpg The plan is for the models to go into Jon Stockill's model database, and for the DOF data to go in there too, once some stuff about radio towers gets worked out. Then the downloadable scenery adds will include tall buildings, smokestacks, and other things. Other than the radio tower stuff, my main holdup is getting the models to look nicer. The way I'm proceding for the generic tall building models: I have a set of Blender models, all meters tall, with cross-sections of 50m square, 60m square, 60m quare with a 5m/side right triangle taken out of the corners, 30m x 60m, 25m radius circle, etc. I am in the process of making small (typically 32x32, sometimes 64x64, rarely 128x128) textures of building sides, typically tiny sections cropped from photos and then processed in the Gimp. My plan is to mix and match these to create a very wide variety of buildings that can be drawn from randomly when the .stg files are created. I'm not yet happy with the way most of them look. Some of them have alignment issues with horizontal/vertical features on the texture tiles that I thought I'd fixed, but haven't really. Some look very good close up, but from a distance look like odd solid color blocks. Most need roofs. None have hazard lights. And there will be more of them. So this isn't ready yet. But the pics should give an idea of how this can go. Re: frame rates. You can see the frame rates I was getting in the lower-right-hand corner. This is with a Gf4 Ti4600, but at 1600x1200. I did this approach again without the buildings in the scene, and got framerates that were 1-4 fps larger. And Manhattan is a worst-case scenario. So I don't think framerates are going to be much of a problem. That's really nice ! But if all these models are placed automagically, what would happen to model that represent the real buildings ? I mean : if I create the Empire State Building and put it in fgfsdb, would there be a hole around it or would it be in collision with its generic clone ? It already happens at SFO with the radio towers and they need to be removed manually. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mac os x simgear build break with RenderTexture.cpp
Quoting David Luff : I have an inkling in the back of my mind that it might also possibly be useful for drawing impostors for the 3D cloud rendering, but that's just a wild guess. Mark Harris, who wrote both RenderTexture and 3d clouds, used the framebuffer to do the latter's impostors. But the resulting image has to be copied to the texture memory and this could be avoided by the use of pbuffer. Note that if we are careful to render to texture *before* the initial glClear, we could use this path ( drawing to frame back buffer and then copy image to texture memory ) for systems that will not support pbuffer. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear CVS errors
Erik Hofman a écrit : John Wojnaroski wrote: Started building a CVS version and bombed out in Simgear with the following: RenderTexture.cpp: In method `RenderTexture::Render RenderTexture.cpp:151: `GLX_RENDER_TYPE_SGIX' undec RenderTexture.cpp:1774: `GLX_SGIX_pbuffer' undeclar RenderTexture.cpp:1779: `GLX_SGIX_fbconfig' undecla make[2]: *** [RenderTexture.o] Error 1 make[1]: *** [install-recursive] Error 1 make: *** [install-recursive] Error 1 looks like a GL extension thingy for SGI machines. No, it's a standard glx extension that should be supported by all UNIX/Linux OpenGL implementations. Any suggestions where to look or add or specify as an option or turn off You might want to check if the glx-dev package is installed, or the glx.h header is present on your system. Perhaps John can enlight us on the system he use. My bet would be on cygwin looking the way the error was clipped. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear CVS errors
Hermann Schiffer a écrit : Am Sunday, 6. February 2005 14:12 schrieb Frederic Bouvier: Erik Hofman a écrit : off You might want to check if the glx-dev package is installed, or the glx.h header is present on your system. Perhaps John can enlight us on the system he use. My bet would be on cygwin looking the way the error was clipped. Hi, I have the same problem on Debian. Theres two different glx.h residing on my system, one in /usr/include/GL and one in /usr/X11R6/include/GL. I tried several combinations of the two files in the two places, no luck though. On my debian system /usr/include/GL/glx.h is a link to /usr/X11R6/include/GL/glx.h -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear version 9.2 Help Request
Martin Spott wrote: Erik Hofman wrote: Maybe someone else can step in and explain the 942058 part of the file called 942058.stg ? I cannot _explain_ it but I could point an an implementation of the algorithm that's used to determine this number. This is part of TerraGear: TerraGear/src/Prep/Tower/calc-tile.pl Well, there is nothing to explain. It is just a magic/bucket number that is a function of latitude and longitude of the tile and is used to index scenery tiles. A tile being a 1/8 of a degree at the equator but its width shrink to 1/4 and 1/2 when the longitude increase ( in absolute value ). The number is computed in simgear/bucket/newbucket.[hc]xx -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun WIN32 double quoted path bug
Geoff Air a écrit :
Hi Fred, and others ...
First I would say I LOVE fgrun ... my hat off
to those in our community who 'remember' all the
130 plus command line options for FlightGear ... yet
they are part of its 'power' ... as well as giving
a beautiful preview of the aircraft ... fgrun takes the
angst out of changing switches ...
Before 'running' FlightGear, in run_win32.cxx,
the Wizard::run_fgfs(string args) function
correctly encases the path in double quotes, needed if a
space exists in any of the directory names ... but it
uses the passed args to compute the lengths ... which will
always work for the first 'change' ... but will then
be 'wrong' in the second change to the copy 'line' ...
Here is the patch, in diff format -
40c40
string::size_type pos_fg_root = args.find( --fg-root= ),
---
string::size_type pos_fg_root = line.find( --fg-root= ),
44c44
end_fg_root = args.find( --, pos_fg_root + 10 );
---
end_fg_root = line.find( --, pos_fg_root + 10 );
49c49
string::size_type pos_fg_scenery = args.find( --fg-scenery= ),
---
string::size_type pos_fg_scenery = line.find( --fg-scenery= ),
53c53
end_fg_scenery = args.find( --, pos_fg_scenery + 13 );
---
end_fg_scenery = line.find( --, pos_fg_scenery + 13 );
Without this 'fix' I got things like --fg-scenery=c:\mypath
Thanks, strange I didn't noticed the problem.
I wrote a simple service, for another project, to do the
same - it is NEEDED quite frequently in win32 ;=)) - which you
could add/use/modify -
int fg_prefs::encase_arg( string line, string arg ) {
int iret = 0;
string ar = --; // start option argument
string are = --; // to next, if any
ar += arg; // add the current argument/option
ar += =; // add EQUALS
size_t pos1 = line.find(ar); // find, like '--fg-root='
if( pos1 != string::npos ) { // if FOUND
size_t sz = pos1 + ar.size(); // get the arg size
size_t pos2 = line.find( are, sz ); // find next arg beginning
if( pos2 == string::npos ) { // if NOT FOUND
pos2 = line.size();
}
line.insert( pos2, \ ); // pop in the quotes, at the end first
line.insert( sz, \ ); // then at the front of the 'path'
iret = 1; // advise done
}
return iret;
}
You will note I check the find of the 'next', in case it
is the last, or only option, in the args passed ...
I would also be interested in whether my use of 'size_t',
in place of the rather long 'string::size_type' works
in all the ports ...
I use msvc7, in XP, cygwin not installed, so also do not
use pthreads ... I added a switch, HAVE_PTHREAD, for things
like -
#ifdef HAVE_PTHREAD
#include pthread.h
#endif // #ifdef HAVE_PTHREAD
if anyone is interested, or headed this direction ...
I need fgrun to 'return', so I can 'select' other things,
and run (the same or different) FG, with a changed
command ... rather than at present, it shows a modal
dialog, and goes into an infinite wait, until FG
quits ... thus do not need pthreads to compile, run ...
the pthread library is available for MSVC developers :
http://sources.redhat.com/pthreads-win32/
-Fred
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug: FG 0.9.8 won't start over land in Britain...
Quoting Steve Hosgood : On Thu, 2005-02-17 at 15:09, Steve Hosgood wrote: Sounds bizarre, but this is quite reproduceable: if you *don't* have the w010n50 scenery tile loaded and use the command-line params --lat=51.6 --lon=-4.0 to start FlightGear, then it starts up just fine. There is a numerical problem at startup. Try --lat=51.6 --lon=-4.001 -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug: FG 0.9.8 won't start over land in Britain...
Quoting Steve Hosgood : Might I propose the FGFS gods avoid causing pointless grief for newbies and insert a fragment of code in the command-line parsing to the effect of: /* KLUDGE: FIXME: avoid hang when starting on a tile boundary */ if (startup_long == floor(startup_long)) startup_long += 0.0001; if (startup_lat == floor(startup_lat)) startup_lat += 0.0001; (or whatever). The tile boundary is not at integral degrees. They can be at .125, .250, .375, .5, .625, .75 and .875 ( every 1/8 of a degree ) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fun with the FAA DOF.
Jon Stockill a écrit : Frederic Bouvier wrote: That's really nice ! But if all these models are placed automagically, what would happen to model that represent the real buildings ? I mean : if I create the Empire State Building and put it in fgfsdb, would there be a hole around it or would it be in collision with its generic clone ? It already happens at SFO with the radio towers and they need to be removed manually. Assuming there's a unique ID in the DOF (I've not seen the file yet) I'll maintain an exclusions list, so that when an updated DOF is imported such buildings can be ignored because we have a better version available. http://frbouvi.free.fr/flightsim/fgfs-sfo-generic-buildings.jpg -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fun with the FAA DOF.
Quoting Erik Hofman [EMAIL PROTECTED]: Frederic Bouvier wrote: Jon Stockill a écrit : Assuming there's a unique ID in the DOF (I've not seen the file yet) I'll maintain an exclusions list, so that when an updated DOF is imported such buildings can be ignored because we have a better version available. http://frbouvi.free.fr/flightsim/fgfs-sfo-generic-buildings.jpg Are these generic buildings now officilally part of the database? I don't know if it is official, but they are in the database I downloaded recently. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fun with the FAA DOF.
Quoting Erik Hofman [EMAIL PROTECTED]: Frederic Bouvier wrote: Quoting Erik Hofman [EMAIL PROTECTED]: Are these generic buildings now officilally part of the database? I don't know if it is official, but they are in the database I downloaded recently. Cool, that would make the scenery much more realistic IMHO. I think the problem is that your models are not listed in the database then? If they where they would probably overwrite the default ones (provided they are located at _exactly_ the same location). I think this is nearly impossible to have the position that match. It should be better to have areas of exclusion, either rectangular ( 2 points ), or circular ( center + radius ). -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Segfault from todays CVS
Quoting Frederic Bouvier: Quoting Mathias Fröhlich : Jon, I cannot reproduce this. It just works for me with a plain cvs checkout using that scenry tile from Scenery-0.9.8. On Freitag 18 Februar 2005 01:24, Jon Stockill wrote: (gdb) bt #0 0x0ce8b760 in ?? () #1 0x40142974 in __dynamic_cast (from=0xce8b760, to=0x8548f9c typeinfo for ssgBase, require_public=139557448, address=0x0, sub=0xbfffee80, subptr=0xbfffee8b) at ../../gcc-2.95.3/gcc/cp/tinfo2.cc:282 #2 0x081241cc in FGGroundCache::get_agl () From that backtrace: There is exactly one dynamic_cast in this function. In theory it should never happen that the argument to that dynamic_cast is zero. Since I cannot reproduce it myself, can you help me? Could you please apply the attached patch and tell me of some of thouse new cerr output lines triggers? I don't know if it is true for gcc, but with MSVC, rtti needs to be activated with a specific compile-time option otherwise the result is unpredictable. And Jon seems to use an old version of gcc : 2.95.3 -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Segfault from todays CVS
Quoting Mathias Fröhlich : Jon, I cannot reproduce this. It just works for me with a plain cvs checkout using that scenry tile from Scenery-0.9.8. On Freitag 18 Februar 2005 01:24, Jon Stockill wrote: (gdb) bt #0 0x0ce8b760 in ?? () #1 0x40142974 in __dynamic_cast (from=0xce8b760, to=0x8548f9c typeinfo for ssgBase, require_public=139557448, address=0x0, sub=0xbfffee80, subptr=0xbfffee8b) at ../../gcc-2.95.3/gcc/cp/tinfo2.cc:282 #2 0x081241cc in FGGroundCache::get_agl () From that backtrace: There is exactly one dynamic_cast in this function. In theory it should never happen that the argument to that dynamic_cast is zero. Since I cannot reproduce it myself, can you help me? Could you please apply the attached patch and tell me of some of thouse new cerr output lines triggers? I don't know if it is true for gcc, but with MSVC, rtti needs to be activated with a specific compile-time option otherwise the result is unpredictable. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Segfault from todays CVS
Quoting Jon Stockill : Mathias Fröhlich wrote: From that backtrace: There is exactly one dynamic_cast in this function. In theory it should never happen that the argument to that dynamic_cast is zero. Since I cannot reproduce it myself, can you help me? Could you please apply the attached patch and tell me of some of thouse new cerr output lines triggers? After a rebuild (with your patch): (gdb) run --aircraft=hunter --airport=RCSS Starting program: /usr/bin/fgfs --aircraft=hunter --airport=RCSS [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 18031)] Failed to find runway 28R at airport RCSS [New Thread 32769 (LWP 18033)] [New Thread 16386 (LWP 18034)] [New Thread 32771 (LWP 18035)] [New Thread 49156 (LWP 18036)] Altitude = 18 Temp at alt (C) = 12 Temp sea level (C) = 12.0348 Altitude = 18 Dewpoint at alt (C) = 10 Dewpoint at sea level (C) = 10.0036 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 18031)] 0x0cdf665b in ?? () (gdb) bt #0 0x0cdf665b in ?? () #1 0x in ?? () #2 0x40142974 in __dynamic_cast (from=0xcdf6658, to=0x854ca9c typeinfo for ssgBase, require_public=139573480, address=0x0, sub=0x405d49d0 main_arena+16, subptr=0x38) at ../../gcc-2.95.3/gcc/cp/tinfo2.cc:282 #3 0x0812233d in FGGroundCache::addAndFlattenLeaf (this=0xb060818, ty=4, l=0x5153f0a8, ia=0xcdf6658, xform=0xb0f0) at groundcache.cxx:159 #4 0x0812281f in FGGroundCache::putSurfaceLeafIntoCache (this=0xb060818, sp=0xb320, xform=0xb0f0, sphIsec=true, down=0xb2c0, l=0x5153f0a8) at groundcache.cxx:260 #5 0x08122d5a in FGGroundCache::cache_fill (this=0xb060818, branch=0x513ffc78, xform=0xb0f0, sp=0xb320, down=0xb2c0, wsp=0xb2d0) at groundcache.cxx:337 #6 0x08122cf7 in FGGroundCache::cache_fill (this=0xb060818, branch=0xcc15720, xform=0xb0f0, sp=0xb320, down=0xb2c0, wsp=0xb2d0) at groundcache.cxx:323 #7 0x08122cf7 in FGGroundCache::cache_fill (this=0xb060818, branch=0xcbd7be8, xform=0xb0f0, sp=0xb320, down=0xb2c0, wsp=0xb2d0) at groundcache.cxx:323 #8 0x08122cf7 in FGGroundCache::cache_fill (this=0xb05c818, branch=0xc3b9b70, xform=0xb0f0, sp=0xb320, down=0xb2c0, wsp=0xb2d0) at groundcache.cxx:323 #9 0x08122cf7 in FGGroundCache::cache_fill (this=0xb05c818, branch=0xcbb2a10, xform=0xb0f0, sp=0xb320, down=0xb2c0, wsp=0xb2d0) at groundcache.cxx:323 #10 0x08122cf7 in FGGroundCache::cache_fill (this=0xb05c818, branch=0x8ff0118, xform=0xb280, sp=0xb320, down=0xb2c0, wsp=0xb2d0) at groundcache.cxx:323 #11 0x08122cf7 in FGGroundCache::cache_fill (this=0xb05c818, branch=0x8ff0090, xform=0xb280, sp=0xb320, down=0xb2c0, wsp=0xb2d0) ---Type return to continue, or q return to quit--- at groundcache.cxx:323 #12 0x08123075 in FGGroundCache::prepare_ground_cache (this=0xb05c818, ref_time=0, pt=0xb3e0, rad=10.407214164733887) at groundcache.cxx:403 #13 0x08121068 in FGInterface::prepare_ground_cache_m (this=0xb05c178, ref_time=0, pt=0xb3e0, rad=10.407214164733887) at flight.cxx:796 #14 0x081b06c2 in YASim::update (this=0xb05c178, dt=0.81665) at YASim.cxx:202 #15 0x08051d6a in fgUpdateTimeDepCalcs () at main.cxx:167 #16 0x08052759 in fgMainLoop () at main.cxx:431 #17 0x08086232 in GLUTidle () at fg_os.cxx:114 #18 0x4009b1c0 in idleWait () from /usr/local/lib/libglut.so.3 #19 0x4009b8bb in glutMainLoop () from /usr/local/lib/libglut.so.3 #20 0x08054d1d in fgMainInit (argc=3, argv=0xb7e4) at main.cxx:958 #21 0x08051746 in main (argc=3, argv=0xb7e4) at bootstrap.cxx:192 I can't explain the gcc version reported there though, because: gcc -v Reading specs from /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/specs Configured with: ../gcc-3.3.4/configure --prefix=/usr --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld --verbose --target=i486-slackware-linux --host=i486-slackware-linux Thread model: posix gcc version 3.3.4 Are you sure your runtime librairies ( that seems to be compiled with gcc-2.95.3 ) match your compiler ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas release candidate
Dave, How about retrying to make a release ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] small error in CVS base package ?
Martin Spott wrote : Hello, I'm currently importing the base package models and objects into the Scenery database. As I'm picking some information from the base package I realized that there's a linke break missing in data/Scenery/Objects/w130n30/w123n37/942066.stg between coit-tower-fb.xml and ggb-fb.xml Confirmed here -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: PATCH: Pathnames in scenery models
Quoting Melchior FRANZ : * Erik Hofman -- Wednesday 23 February 2005 10:03: [absolute paths in *.ac files] Is there a reason to change the path in AC3D files? As far as I know the path is neglected anyhow. These absolute paths are a bit annoying when one wants to view a model in a 3D editor, which respects them. For example, if you go to Aircraft/j3cub/Models and call $ ppe j3cub.ac, you'll see the model with red/white default texture. In most other models the correct textures are shown. I always strip the local path from my models, and I would like everyone to do that. But I wouldn't really change them in CVS now. In a perfect world there would be a script in CVSROOT that would automatically remove these paths in *.ac files, remove trailing spaces in all text files, etc. (Oh, and it would also replace all leading spaces in xml files by tabs ... :-) I usually strip them but I could have missed some. But I thought it was not used by the plib loader ( PPE use plib isn't it ? ). Could we lobby Willan Germano to strip them in the AC exporter ( Melchior ? ) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: PATCH: Pathnames in scenery models
Quoting Jim Wilson : The ac3d editor does that as well. It seems to strip off the path on loading if the absolute path fails. As does the AC loader in plib. It seems odd then that ppe isn't doing the same. Does the ac3d editor generate absolute path ? or is it a feature of the Blender AC exporter ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] More info on seg fault, How?
mat churchill wrote : I'm getting seg faults 25% - 50% of the time when I try to start fg. This is on a fresh install of Mandrake 10.1 with the latest CVS of plib, simgear, flightgear, with the latest nvidia drivers. e.g. [EMAIL PROTECTED] mat]$ fgfs --fg-root=/home/Flightgear/data --fg-scenery=/home/Flightgear/World/work/Scenery-old --airport-id=LFMN --runway=4L --aircraft=b1900d --enable-game-mode --enable-random-objects --enable-horizon-effect --timeofday=noon --enable-ai-models --atlas=socket,out,5,localhost,5500,udp --verbose it then crashes before or during the spash screen, like this. [hash.c:395] failed read [hash.c:395] failed read [hash.c:395] failed read Segmentation fault (core dumped) I'm finding it hard to cause the seg fault happen, it seems to be intermittent. Is there a way to get more info from FG other than using --verbose ? One of these options : --log-level=bulk --log-level=debug --log-level=info --log-level=warn --log-level=alert -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone using TomTom POI files for scenery
Quoting Martin Spott : If I may quote Frederic Bouvier (regarding FGSD): It shouldn't be too difficult. Just a matter of wrapping up the FGSD_TriangleObject class into a main function. but nobody did that. Work in (slow) progress. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Anyone using TomTom POI files for scenery
Quoting Oliver C. : On Wednesday 02 March 2005 11:14, Melchior FRANZ wrote: * Martin Spott -- Wednesday 02 March 2005 10:46: Your intention is clear, it's just that I don't share everyting of it. ... and you don't need to. Just keep the number of 512x512 textures as low as possible, especially for objects with reduced importance. Not everyone has a fast and cheap internet connection. Sigh ... What we need is support for texture compression in flightgear and textures that are stored in such a way, in other words a file format that uses and supports texture compression. Not using texture compression is a waste of video memory. It shouldn't prevent modellers to be careful with texture size. I usually use big textures when modelling to help me position texture coordinates precisely but I reduce them when submitting the model. Anyway, at distance, you only see a reduced texture created by mipmap generation. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Making FlightGear more deterministic
Quoting Erik Hofman : Drew wrote: Hey All, I'm running flightgear on Windows, and have noticed that it seems to use up all of the available processing time, and because of this, it seems to get jumpy when other applications are being used while FlightGear is running. I noticed that I can try to bump up the priority of FlightGear, and everything else comes to a complete halt. I did experience that running Acrobat Reader and FlightGEar simultaneously does cause this behavior. To my opinion there is just one thing that can cause this, another application is also using OpenGL (or DirectX?) for it's rendering... This is done more and more to get hardware support for screen rendering. You might want to experiment a bit to see which program that might be. There is the property /sim/frame-rate-throttle-hz that could be used to limit the framerate but the source should be modified to call a system sleep method ( with a fine resolution, for example pthread_cond_timedwait ) instead of looping wildly. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Making FlightGear more deterministic
Quoting Andy Ross: * Hopefully in a CPU-friendly way. I know that older versions of the NVidia drivers did this by spinning in a polling loop inside the driver. I'm not sure if this has been fixed or not. From my experience, the latest non-beta Windows NVidia driver seems to eat CPU even with sync to vblank enabled. The CPU usage is always 100%. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
