Re: [Flightgear-devel] Spitfire
Vivian Meazza wrote: plib.ssgAux has a particle system that can simulate smoke. Attach one to an animation object and there you have it. Any takers? Someone (David Megginson?) mentioned the particle system when the subject of smoke was brought up some time ago. It may have been me but nothing ever came of it. Can you point me at some more detail? What I am proposing is to derive a new class from SGAnimation that contains a ssgaParticleSystem object. The aircraft xml file specifies the object's location wrt the airframe reference point and color/type of smoke etc. Individual particles are updated every frame according to the laws of physics. Some experimentation will be involved to determine the best number and size of particles. You can view the ssgaParticleSystem documentation and examples at the plib website, http://plib.sourceforge.net/ssgAux/index.html. I don't think the SGAnimation class hierarchy is documented but there are plenty of derived classes to get ideas from. This could be a good first project for someone getting involved with flightgear. It is relatively small and self-contained and provides some exposure to plib, simgear and flightgear. Plus it has obvious visual feedback. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Spitfire
Vivian Meazza wrote: Ampere K. Hardraade wrote Sent: 26 July 2004 03:13 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Spitfire To create smoke, we will need two things: smoke emitter and smoke object. [snip] Good analysis. How much of this already exists, either in the context of 3d clouds or AI? plib.ssgAux has a particle system that can simulate smoke. Attach one to an animation object and there you have it. Any takers? Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172
Jim Wilson wrote:
globals-get_tile_mgr()-all_queues_empty() and cur_fdm_state-get_inited())
{
^^^
^^^
Same here.
That's a head scratcher. Never would have thought that would compile like
that. Learn something new everyday.
C++ provides keyword equivalents to some operators:
and
and_eq =
bitand
bitor |
compl ~
not !
or ||
or_eq |=
xor ^
xor_eq ^=
not_eq !=
However it seems that we should use the traditional operators to prevent
msvc from choking.
Bernie
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
On Wed, 07 Apr 2004 17:20:47 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Bernie Bright wrote: On Tue, 06 Apr 2004 13:52:28 -0700 Andy Ross wrote: Sure. This should work right now. The only bits missing are the autotools magic to do the detection and set up the makefiles appropriately. I fear autoconf, I really do... Does someone with a more solid handle on these things want to help out? :) For starters we could change the glut test in configure.ac to something like: Bernie, I added another patch to CVS to do this because it caused a number of problems for systems without SDL installed. This approach doesn't rely on SDL provided autoconf macros. We could add sdl.m4 to FlightGear. A lot of projects have an m4 directory to collect such things. We would then pass that directory to aclocal... aclocal -I./m4. Just updated cvs. Your fix looks for GL/glut.h when --enable-sdl is specified. I thought it was supposed to be either or. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
On Tue, 06 Apr 2004 13:52:28 -0700 Andy Ross [EMAIL PROTECTED] wrote: Curtis L. Olson wrote: Probably the best short term solution is to make sure we can build with both SDL and glut and let the builder decide? Sure. This should work right now. The only bits missing are the autotools magic to do the detection and set up the makefiles appropriately. I fear autoconf, I really do... Does someone with a more solid handle on these things want to help out? :) For starters we could change the glut test in configure.ac to something like: --- dnl Check for SDL if enabled. AC_ARG_ENABLE(sdl, [ --enable-sdlConfigure to use SDL instead of GLUT], enable_sdl=yes, enable_sdl=) if test x$enable_sdl = xyes ; then sdl_version=1.2.0 AM_PATH_SDL($sdl_version, use_sdl=yes, use_sdl=) CPPFLAGS=$CPPFLAGS $SDL_CFLAGS LIBS=$LIBS $SDL_LIBS else dnl check for glut location AC_CHECK_HEADER(GL/glut.h) if test x$ac_cv_header_GL_glut_h = xyes; then AC_DEFINE([FG_GLUT_H], GL/glut.h, [Define as glut.h include location]) else AC_CHECK_HEADER(GLUT/glut.h) if test x$ac_cv_header_GLUT_glut_h = xyes; then AC_DEFINE([FG_GLUT_H], GLUT/glut.h, [Define as glut.h include location])else echo Neither GL/glut.h nor GLUT/glut.h found. Cannot continue exit fi fi fi --- Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More 0.9.4pre1 feedback
On Tue, 23 Mar 2004 17:39:27 + (GMT) Jon Stockill [EMAIL PROTECTED] wrote: On Tue, 23 Mar 2004, David Luff wrote: Seems to work fine on Cygwin, apart from the --with-package=PREFIX configuration issues already posted. Nice job everyone. Yup - it's a flawless build on slackware with: plib 1.8.1 SimGear 0.5.4pre1 FlighGear 0.9.4pre1 I've not had chance to do much testing yet, but first impressions are good. I'll also be including fgrun in the package - is there likely to be a release newer than 0.4.2 in time to include in the packages? I've just released 0.4.3. Changes include: * Maintain proper aspect ratio of aircraft preview window. * Added control to refresh airport and runway data. * Display aircraft description. * Smarter handling of aircraft aliases. * Fullscreen option at startup. Many thanks to Frederic Bouvier for his input and patches. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More 0.9.4pre1 feedback
On Tue, 23 Mar 2004 19:34:38 +0100 (CET) Frederic BOUVIER [EMAIL PROTECTED] wrote: Erik Hofman wrote: Frederic BOUVIER wrote: Erik Hofman wrote: Jon Stockill wrote: I'll also be including fgrun in the package - is there likely to be a release newer than 0.4.2 in time to include in the packages? What's wrong with 0.4.2, it's one week old? Nothing wrong, it's just that we made a few enhancement, like aircraft alias filtering, display of aircraft name instead of file names, constant aspect ratio, airport list refresh button or small fix in resizing. And where's 0.4.3? Not for the moment, should ask Bernie. Now that you mention it, there have been a lot of updates the past 10 days. I will get 0.4.3 out real soon. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Fix for compilation error in panel.cxx: `truncf' undeclared
On Tue, 27 Jan 2004 23:50:56 -0500 Eric L Hathaway [EMAIL PROTECTED] wrote: Erik Hoffman wrote: Bernie Bright wrote: / Compiles okay on Mandrake 9.2/10.0 (glibc-2.3.3 and gcc-3.3.2). However this// should really be tested for by the configure script - AC_CHECK_FUNCS(truncf)// and panel.cxx should then contain: / I'll add a test for it. Erik Erik, Unfortunately, FlightGear still doesn't compile on RedHat 7.3, even with the above configure script check for truncf (I haven't checked it out on RedHat 9 yet). I did figure out how to get it to work though (see below). Perhaps we need to reconsider this whole truncf() thing. FlightGear is supposed to be written in C++ not C99. Maybe we could add an equivalent function to SimGear. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fix for compilation error in panel.cxx: `truncf' undeclared
On Mon, 26 Jan 2004 23:03:50 -0500
Eric L Hathaway [EMAIL PROTECTED] wrote:
Allow me to de-lurk for a minute to report a compilation problem, along
with a fix.
Current (10:00pm EST, 2003-1-26) CVS checkouts of FlightGear fail to
compile on my Linux box. Here is the relevant part of the output from
'make', showing the error:
--- Begin ---
g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src
-I/usr/X11R6/include -Wall -O5 -fomit-frame-pointer -ffast-math
-funroll-loops -march=athlon -D_REENTRANT -c -o panel.o `test -f
panel.cxx || echo './'`panel.cxx
panel.cxx: In method `const char *FGTextLayer::Chunk::getValue ()
const':
panel.cxx:1128: `truncf' undeclared (first use this function)
panel.cxx:1128: (Each undeclared identifier is reported only once for
each function it appears in.)
make[3]: *** [panel.o] Error 1
--- End ---
It would appear that the truncf function is not being declared. I did
some searching on Google, and quickly found a thread starting with the
following message posted to a glibc mailing list:
http://sources.redhat.com/ml/bug-glibc/2001-10/msg00015.html
Apparently, the truncf function was introduced in the C99 standard, and
to use such functions in glibc you must define _ISOC99_SOURCE (or
_GNU_SOURCE) in order for the functions to be properly declared by
math.h. See the follow-up messages to the above glibc mailing list
posting for more info. I wrote a simple five line C program to test
truncf, and indeed it didn't work properly unless I added
-D_ISOC99_SOURCE or -D_GNU_SOURCE to the list of arguments to gcc.
I checked that this compilation problem occurs, and the above fix works,
on both a machine running Red Hat 7.3 (glibc-2.2.5, gcc-2.96), and
another running Red Hat 9 (glibc-2.3.2, gcc-3.2.2).
Compiles okay on Mandrake 9.2/10.0 (glibc-2.3.3 and gcc-3.3.2). However this
should really be tested for by the configure script - AC_CHECK_FUNCS(truncf)
and panel.cxx should then contain:
#ifndef HAVE_TRUNCF
inline float truncf (float d) { ...
#endif
Cheers,
Bernie
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] enrty and exit points of main loop
On Fri, 23 Jan 2004 15:39:23 -0500 Snyder Adam D Civ AFRL/VACD [EMAIL PROTECTED] wrote: Hello, I am trying to add some calls to flightgear's main loop in order to set up shared memory and semaphores, and then remove them when FG exits. The easy part is the initialization but I can't find a good spot in the code to do any cleanup, due to the glutMainLoop. Any suggestions? Have you considered registering your cleanup function with atexit()? Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Ho Ho Ho
Just discovered the seasonal ufo model. Nice work Erik. One problem however, the sound is messed up. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Checking if there is a connection with netChannel
On Tue, 02 Dec 2003 20:40:51 -0500
Norman Vine [EMAIL PROTECTED] wrote:
Seamus Thomas Carroll writes:
On the client side I thought about using netChannel::close to inform the
server that the socket is closed but the function is never
called. netChannel::close is called in the clients destructor but the
destructor is never called because FGGlobals *globals is never deleted
(from what I can tell) which in turn would delete my client.
Any thoughts on the matter? Would putting delete globals somewhere in
the code which down the line would call netChannel::close() be the
solution?
Easy enough to test
try moving
globals = new FGGlobals;
out of main,cxx fgMainInit( int argc, char **argv ) {
into bootstrap.cxx
main(int argc, char **argv)
{
...
globals = new FGGlobals;
// FIXME: add other, more specific
// exceptions.
try {
fgMainInit(argc, argv);
} catch (sg_throwable t) {
// We must use cerr rather than
// logging, since logging may be
// disabled.
cerr Fatal error: t.getFormattedMessage()
\n (received from t.getOrigin() ')' endl;
exit(1);
}
delete globals;
}
globals will not be deleted if an exception is caught. This is a good case
for using std::auto_ptr. Alternatively if globals was an object and not a
pointer it would be destroyed automatically at exit.
Bernie
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] read not excepting more than one client
On Fri, 28 Nov 2003 22:45:24 -0700 Seamus Thomas Carroll [EMAIL PROTECTED] wrote: Hi, I have created a server which has one SGSocket object listening for clients that want to connect. The problem I am having is when a second client sends its connect info to the server the server never gets the message. Note that the server is listening using readline and that the connection is tcp. I have tried two different clients and they both work if they are the first one to connect. Are there any restrictions on a SG_IO_IN socket that I should be aware of? Any other suggestions? This problem could be with my code but I want to ask the question before I spend a lot of time on looking for the problem. What you are seeing is normal behaviour for SGSocket. You might be better served by using plib.net. This is what FlightGear uses for the http and prop servers. See src/Network/httpd.cxx and src/Network/props.cxx for examples. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear SGSocket returning -1
On Thu, 27 Nov 2003 07:23:30 -0600 Curtis L. Olson [EMAIL PROTECTED] wrote: Curtis L. Olson writes: Bernie Bright writes: SGSocket::readline() and SGSocket::read() do act differently. For a server, readline() correctly handles the accept and reads from the new socket. read() also handles the accept but reads from the master socket. I'm not sure if this is intentional or if its a bug. Someone else wrote in reporting a problem here. THey also said that reading from the new socket fixed the problem in read(). If it seems to make sense, maybe we should make read() read from the new socket? It looks like readline() uses sock.recv() for UDP style sockets and client-recv() for tcp style sockets. I will make read() work the same way and hope I don't break anything. Judging from style and lack of familiarity, I don't think it was me who wrote the code. I think I'm responsible for the current code. I remember rewriting it using plib.net a couple of years ago. I agree that read() should work the same as readline() but I don't remember why it wasn't so in the first place. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear SGSocket returning -1
On Wed, 26 Nov 2003 16:59:53 -0700 Seamus Thomas Carroll [EMAIL PROTECTED] wrote: Hi, I am trying to recieve a message using SGSocket::read. SGSocket::read returns zero bytes read until about the time I am expecting the first message to be recieved. From here on SGSocket::read returns that -1 bytes have been read from the socket. I have looked around (simgear docs, plib) and I cant find out what the -1 is supposed to indicate. Does anyone know? On unix -1 indicates an error. The actual error code is in the external variable errno. Call strerror(errno) to convert errno to a string. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG logo Slovenian flag
On Thu, 27 Nov 2003 03:43:59 + Lee Elliott [EMAIL PROTECTED] wrote: Is there anyway to turn the console output back on? I've learnt quite a bit from looking at it and it's also helped me sort out a few problems. I understand the desire to make it quieter but I'd like it to be optional. --log-level=info Available levels are alert, warn, info, debug and bulk. alert is the new default. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear SGSocket returning -1
On Wed, 26 Nov 2003 18:04:50 -0700 Seamus Thomas Carroll [EMAIL PROTECTED] wrote: I output the error and I am getting: Transport endpoint is not connected From man recv ENOTCONN The socket is associated with a connection-oriented protocol and has not been connected (see connect(2) and accept(2)). If its the server side that is failing then accept() wasn't called or you are trying to read from the master socket. But see below... The strange part is if I put '\n' at the end of the message and read with 'readline' the message is successfully recieved. Is this a problem with 'read'? SGSocket::readline() and SGSocket::read() do act differently. For a server, readline() correctly handles the accept and reads from the new socket. read() also handles the accept but reads from the master socket. I'm not sure if this is intentional or if its a bug. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: New timer code ported onto old
On Thu, 20 Nov 2003 15:28:49 -0800 Andy Ross [EMAIL PROTECTED] wrote: Frederic Bouvier wrote: There are people that don't use automake to build flightgear and they would be gratefull if they could continue to build without having to duplicate stuff. I'm going to have to start writing clearer, I guess. Let me say it again: I *want* to put the nasal.h file into a subdirectory. Tell me how. Editting C++ code is not sufficient. Judging from the other Makefile.am files, try adding includedir = @includedir@/nasal to your Makefile.am and re-run automake, etc. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway editors
On Wed, 19 Nov 2003 18:15:00 + Jon Stockill [EMAIL PROTECTED] wrote: There was much talk a while ago about taxiway editors (ISTR there were at least a couple being worked on). How're these progressing, and where can I find them? I'm working on a bunch of airfield buildings, and it'd be nice to sort out the taxiways at the same time. I'm working on an AFCAD-like taxiway editor for the FlightGear Scenery Designer, http://sourceforge.net/projects/fgsd/. Checkout the taxiway_editor_3 branch. Most of the basic editing functionality is present. The resultant output is an xml file. Note, recent changes to fltk v2 means my stuff won't compile any more. I will fix it real soon now. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] fgrun - runtime error
On Mon, 10 Nov 2003 00:14:07 + Richard Hornby [EMAIL PROTECTED] wrote: This may be one for Erik ... I am using FG 0.9.3 CVS version. I have compiled fltk and fgrun on SuSE8.2 and both seemed to go fine. I compiled both with --with-x and --with threads. You don't need to specify --with-x since it is the default. fgrun doesn't have a --with-threads option. fltk-1.1 has a --enable-threads option but I've never used it. I suggest you don't either. On running fgrun I get the following message in the console linux:~ # fgrun X_DestroyWindow: BadWindow (invalid Window parameter) 0x2ac X_TranslateCoords: BadWindow (invalid Window parameter) 0x21 X_TranslateCoords: BadWindow (invalid Window parameter) 0x21 and a gray (blank) window entitled FlightGear log (this leaves lines behind it when dragged). fgrun then hangs. This looks like an X-related problem? fltk comes with several programs in the test directory. Try some of those to check your installation. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
On Fri, 07 Nov 2003 02:22:54 +0200 Paul Surgeon [EMAIL PROTECTED] wrote: The menu systems could do with some major enhancments. A nice menu system for picking airports and aircraft, joystick configuration and key mappings would go down well. Getting everything menu driven will help a lot. Most people hate playing in shells passing huge lists of arguments to get what they want. FG Launch Control http://sourceforge.net/projects/fgrun/ is a standalone GUI app that does some of what you describe. We need some nice development tools. In particular a full blown scenery editor that one can use to lay down 3D objects (trees/buildings), taxiways, aprons, roads, rivers, etc. If it's done in OpenGL then you can make it WYSIWYG. One way to do this is to incorporate a scenery edit mode into FlightGear like the one in FLY2. You pause the game and go into edit mode and can lay down trees and objects. Then hit unpause and fly around your creation. I personally think a seperate editor would be the answer since it won't interfere FlightGear development and one can add as many features as one likes. FG Scenery Designer http://sourceforge.net/projects/fgsd/ is another standalone app that lets you modify scenery and place objects. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 0.9.3-pre1b installable package ( revised )
On Sat, 18 Oct 2003 19:18:24 +0200 Frederic Bouvier [EMAIL PROTECTED] wrote: Hi all, This is a notice to those that are downloading the full Win32 package or are going to. I managed to build the excellent Bernie Bright's fgrun program and I added it to a new (80Mb) package that I am uploading right now. Glad you like it! Are there any changes I should know about? I don't do much testing under Windows these days so any feedback would be appreciated. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 0.9.3-pre1b installable package ( revised )
On Sat, 18 Oct 2003 19:38:35 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: Bernie Bright writes: On Sat, 18 Oct 2003 19:18:24 +0200 Frederic Bouvier [EMAIL PROTECTED] wrote: Hi all, This is a notice to those that are downloading the full Win32 package or are going to. I managed to build the excellent Bernie Bright's fgrun program and I added it to a new (80Mb) package that I am uploading right now. Glad you like it! Are there any changes I should know about? I don't do much testing under Windows these days so any feedback would be appreciated. What's fgrun written in? C++ What libs are you using for the gui stuff? FLTK 1.1.x Hosted at sourceforge, http://sourceforge.net/projects/fgrun Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Instrumentation adf.cxx, 1.1, 1.2
On Thu, 02 Oct 2003 03:47:35 -0500
Erik Hofman [EMAIL PROTECTED] wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Instrumentation
In directory baron:/tmp/cvs-serv9276
Modified Files:
adf.cxx
Log Message:
Work around a MipsPro 7.2 STL problem
Index: adf.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Instrumentation/adf.cxx,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -r1.1 -r1.2
*** adf.cxx 1 Oct 2003 21:10:34 - 1.1
--- adf.cxx 2 Oct 2003 08:47:33 - 1.2
***
*** 115,119
// If it's off, don't bother.
string mode = _mode_node-getStringValue();
! if (!_transmitter_valid || (mode != bfo mode != adf)) {
set_bearing(delta_time_sec, 90);
_ident_node-setStringValue();
--- 115,120
// If it's off, don't bother.
string mode = _mode_node-getStringValue();
! if (!_transmitter_valid || (mode != string(bfo) mode !=
string(adf)))! {
set_bearing(delta_time_sec, 90);
_ident_node-setStringValue();
Haven't we seen this or something like it before? Instead of fixing the
code every time wouldn't it be easier to supply the missing comparison
functions for your platform:
inline bool
operator!=( const std::string lhs, const char* rhs )
{
return lhs.compare( rhs ) != 0;
}
inline bool
operator!=( const char* lhs, const std::string rhs )
{
return rhs.compare( lhs ) != 0;
}
Other comparisons could be added if required.
Bernie
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wireeframe and Flat Shaded Display
On Thu, 25 Sep 2003 23:27:46 +0100 James Turner [EMAIL PROTECTED] wrote: As to *why* I as looking at main.cxx - I'm trying to get an idea how complex a conversion to SDL would be - what other people are working in this area? I've got quite a bit of experience with SDL itself, but main.cxx is frightening me. I'm investigating using SDL audio. Originally I modified SGSoundMgr with some success but have dropped that idea and am currently adding SDL audio support to plib.sl. This approach is much more promising and requires minimal changes to FlightGear. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound probs
On Mon, 15 Sep 2003 19:06:10 +0200 Arnt Karlsen [EMAIL PROTECTED] wrote: Are we still interested in migration to LibSDL? (cause I am ;)) ..shoot! Whoever codes it gets the credit for it. ;-) I've got an version sort of working using SDL_mixer. Unfortunately neither SDL nor SDL_mixer have a pitch envelope function so I'll have to code something myself. Initial tests are promising, at least I can hear the engine and gear noises. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Error in runways.dat.gz and basic.dat.gz
A MAR1 -15180 CNN Coprales Chasma: thick air ^^ This can't be the correct altitude! Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] request for comments?
On Tue, 05 Aug 2003 11:23:07 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: I'm even talking about simple things like multitexturing which isn't exactly a new concept (i.e. it's been supported by hardware/opengl since the voodoo-1 days.) Plib unfortunatley has no support for multitexturing. These other scene graphs do, and also support things like imposters which is the technique often used for 3d clouds. We could always create our own fork of plib, or at least plib.ssg, and implement these features ourselves. Its my understanding that plib's author is waiting for the opengl shading language to be standardised before adding any new features. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] metakit
On Thu, 31 Jul 2003 18:24:55 -0500 Jon Berndt [EMAIL PROTECTED] wrote: I've downloaded the latest fgfs, plib, and simgear, and as usual I need to install the latest metakit - which I did. However, the simgear build process doesn't seem to know it exists. I get this when building simgear: checking for mk4.h... yes checking for metakit 2.4.3 or newer... wrong version configure: error: Install metakit 2.4.3 or later first. But, I just installed metakit 2.4.9 (the one that comes with simgear). The lib is in /usr/local/lib/: -rw-r--r--1 Jon None 1833888 Jul 31 16:55 libmk4.a -rwxr-xr-x1 Jon None 659 Jul 31 15:03 libmk4.la What am I doing wrong? Check config.log for the actual cause of the failure. Perhaps you have an earlier version installed somewhere. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] port for beos/zeta!
On Wed, 30 Jul 2003 20:57:08 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Ralf Schuelke wrote: hello coders, wahre can flightgear portet for beos/zeta? ... i hope any coder make this! pleas for answere There has been someone working on a Beos port of FlightGear hasn't it? I don't know what the result was. I attempted a BeOS port many years ago but never got plib to compile. There were just too many opengl problems. Then BeOS went under so I gave up. I no longer run BeOS in any form so someone else can try. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Networknative_fdm.cxx, 1.12, 1.13 net_fdm.hxx, 1.5, 1.6
On Tue, 22 Jul 2003 18:46:14 -0500
Curtis L. Olson [EMAIL PROTECTED] wrote:
Update of /var/cvs/FlightGear-0.9/source/src/Network
In directory baron:/tmp/cvs-serv19507/Network
Modified Files:
native_fdm.cxx net_fdm.hxx
Log Message:
Add gear animation effects to replay.
Index: native_fdm.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Network/native_fdm.cxx,v
retrieving revision 1.12
retrieving revision 1.13
diff -C2 -r1.12 -r1.13
*** native_fdm.cxx22 Jul 2003 20:05:38 - 1.12
--- native_fdm.cxx22 Jul 2003 23:46:11 - 1.13
***
*** 184,187
--- 184,190
SGPropertyNode *node = fgGetNode(/gear/gear, i, true);
net-wow[i] = node-getDoubleValue(wow);
+ net-gear_pos[i] = node-getDoubleValue(position-norm);
+ net-gear_steer[i] = node-getDoubleValue(steering-norm);
+ net-gear_compression[i] =
node-getDoubleValue(compression-norm);
}
***
*** 247,250
--- 250,256
for ( i = 0; i net-num_wheels; ++i ) {
net-wow[i] = htonl(net-wow[i]);
+ net-gear_pos[i] = htonl(net-gear_pos[i]);
+ net-gear_steer[i] = htonl(net-gear_steer[i]);
+ net-gear_compression[i] = htonl(net-gear_compression[i]);
}
net-num_wheels = htonl(net-num_wheels);
***
These latest changes generate a compilation error:
native_fdm.cxx: In function `void FGProps2NetFDM(FGNetFDM*, bool)':
native_fdm.cxx:252: invalid operands of types `float' and `unsigned int' to
binary `operator'
The gear_* members should be converted using htonf() instead of htonl().
A minor nit with htonf() is that it doesn't return the converted value like
the other htonX functions. For consistency I wonder if we should change
this.
Cheers,
Bernie
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG Network interface
On Wed, 16 Jul 2003 08:09:07 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: Christophe DONTAINE writes: Hi, I'm writing a little application to link Aerowinx PS1 simulator to FlightGear to have a better world visualization. (to C. Olson: the project discussed by mail the 18 April) I use the FG 0.9.1 from CVS where I found a java library to drive FG from the network. (I'm updating my CVS to 0.9.2 right now) For now, the flightgear aircraft is only at the good altitude. :D 1° I read into the java library some variables like /position/altitude-ft and I would like know if there is a document listing all the variables. 2° I sent updates from the network and the aircraft is moving... fine. But it seems that updates are too slow. Is there a theorical update frequency to avoid some step in the aircraft flight ? or the faster update is the better update ? Hi, Unfortunately the interface mechanism you are using is not designed to be high bandwidth. I believe it runs at 5hz? and only processes one line/command per iteration. You could try upping the frequency via the command line, --props=socket,bi,20,,5500,tcp. There was a bug where the frequency was always 5Hz regardless of the command line. Hopefully this was fixed. It would work better to send over an FGNetFDM structure (src/Network/net_fdm.hxx) via UDP. Agreed, although it might be tricky from a java app. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG Network interface
On Wed, 16 Jul 2003 08:57:19 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: Bernie Bright writes: Unfortunately the interface mechanism you are using is not designed to be high bandwidth. I believe it runs at 5hz? and only processes one line/command per iteration. You could try upping the frequency via the command line, --props=socket,bi,20,,5500,tcp. There was a bug where the frequency was always 5Hz regardless of the command line. Hopefully this was fixed. Hi Bernie, Another thing that would be helpful would be to process all pending commands each time through rather than just the first in the queue. How hard would it be to make this change? Tricky. We are limited by how plib.net handles line terminators which is controlled by how often netChannel::poll() is called. However we could change PropsChannel::foundTerminator() to handle several commands per line. Commands could be separated with semicolons. Or perhaps some commands could take more than one argument, eg get /foo/bar /foo/baz. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Texture Sizes
On Tue, 8 Jul 2003 15:58:26 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: I think we have some capacity (especially on higher end systems) for cranking more polygons. However, we need to be careful because we might find ourselves throwing 10-100 of these aircraft into a single scene (i.e. landing at a busy airport.) We might be able to get away with 1 high polygon count model, but if we have 10-100 it will kill us ... and if they are all parked at the airport, we might not be able to use LOD to bail us out (like we could if the aircraft were all airborn and flying normal routes with normal separation.) Perhaps we need separate low poly-count models suitable for use as AI aircraft. FS2k2 supports such a feature. Such models wouldn't need 3D cockpits or animations, although retracting landing gear and spinning props might be visually useful. And I suppose being able to jump into the cockpit of an AI aircraft could be fun too, even if only as an observer. Hmmm maybe animations and 3D cockpits could stay. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] plib patch for Solaris
On 1 Jul 2003 13:19:08 GMT Martin Spott [EMAIL PROTECTED] wrote: Erik Hofman [EMAIL PROTECTED] wrote: Could you remove '#include FGJSBBase.h' at line 68 of FGfdmSocket.h and see if this solves your problem? Sorry, no change at all. Is this what people call a classical namespace conflict ? Yup! FGJSBBase.h has a using std::queue statement that clashes with something in one of your system headers. Remove SG_USING_STD(queue); and replace static queue Message* Messages; with static std::queue Message* Messages; This is why using statements in header files are considered bad. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Again: Threaded FlightGear ?
On Tue, 24 Jun 2003 07:46:39 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: [snip] Think about this another way ... do a profile of flightgear. I bet you will find that the graphics rendering portion of FlightGear takes 90-95% of the entire application work load. If you can't find a way to split that up (which is nigh unto impossible since this is all involving opengl which inherently resists threading without a *huge* amount of effort and complexity[1]) then threading the other 5-10% of the work isn't going to gain you a whole lot. For the record, the top 20 functions as reported by oprofile-0.5.3 are: Cpu type: PIII Cpu speed was (MHz estimation) : 807.98 Counter 0 counted CPU_CLK_UNHALTED events (clocks processor is not halted) with a unit mask of 0x00 (No unit mask) count 40 % symbol name 1.02981 ssgSelector::select(unsigned) 1.03343 FGHitList::IntersectBranch(ssgBranch*, double (*) [4], double*, double*) 1.07417 ssgEntity::dirtyBSphere() 1.10563 ssgEntity::getTraversalMask() 1.13437 FGInstrumentLayer::transform() const 1.15995 SGPropertyNode::hash_table::get(char const*) 1.35369 ssgLeaf::cull(sgFrustum*, float (*) [4], int) 1.47658 slEnvelope::applyToVolume(unsigned char*, unsigned char*, int, int) 1.53362 sgXformPnt3(float*, float const*, float const (*) [4]) 1.60288 ssgVtxTable::getNumColours() 1.77896 ssgBranch::recalcBSphere() 2.05825 sgdMakeNormal(double*, double const*, double const*, double const*) 2.1051 SGPropertyNode::hash_table::bucket::get_entry(char const*, bool) 2.2873 sgFrustum::contains(sgSphere const*) const 2.69288 SGPropertyNode::hash_table::hashcode(char const*) 3.03894 ssgVtxTable::getNumVertices() 3.16909 ssgSimpleState::apply() 3.2234 ssgVtxTable::draw_geometry() 4.77468 ssgBranch::cull(sgFrustum*, float (*) [4], int) 4.77513 ssgEntity::cull_test(sgFrustum*, float (*) [4], int) Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sutro tower in CVS
On Sun, 22 Jun 2003 07:11:54 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: Bernie Bright writes: On Sat, 21 Jun 2003 07:32:07 -0400 David Megginson [EMAIL PROTECTED] wrote: Frederic Bouvier writes: The highest point of the bay area is in CVS : http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-sutro-sf.png Wow! Any volunteers for the Bay-area bridges? The closest one to KSFO, I think, is the plain-and-ugly San Mateo bridge (perhaps not its proper name), but the Golden Gate is the one everyone will be looking for. I've got the Bay area bridges but they are in X-Plane format - I also wrote a suitable loader for plib. Unfortunately the license is incompatible with GPL, one of those free but not to make money clauses, and the author seemed reluctant to change it for us. Bernie, is it a license problem with the models or the plib-x-plane-format loader? If it's a loader problem, you could always convert the models off line to something that plib can load by default. The plib loader is LGPL because I wrote it. At the time, the Golden Gate model I was using contained the following statement: In the spirit of freeware this package is released to the general public. It may redistributed as long as it is not for commercial purposes and you include this Readme file in the package. It is my understanding that not for commercial purposes goes against the GPL. However I have just found another X-Plane GG model which is a bit more detailed and seems unencumbered with any license or readme that I can find. I am investigating this one further. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sutro tower in CVS
On Sat, 21 Jun 2003 07:32:07 -0400 David Megginson [EMAIL PROTECTED] wrote: Frederic Bouvier writes: The highest point of the bay area is in CVS : http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-sutro-sf.png Wow! Any volunteers for the Bay-area bridges? The closest one to KSFO, I think, is the plain-and-ugly San Mateo bridge (perhaps not its proper name), but the Golden Gate is the one everyone will be looking for. I've got the Bay area bridges but they are in X-Plane format - I also wrote a suitable loader for plib. Unfortunately the license is incompatible with GPL, one of those free but not to make money clauses, and the author seemed reluctant to change it for us. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: keyboard mapping - spoilers and zoom
On Tue, 10 Jun 2003 17:32:15 - Jim Wilson [EMAIL PROTECTED] wrote: At some point we could think about writing xml files on the fly from gui dialogs, so that flightgear can be run and customized either with or without a text editor. That sounds like a project one of our new volunteers could attempt. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Profiling/Graphics/Menus
On Tue, 10 Jun 2003 17:55:34 +0100 Christopher S Horler [EMAIL PROTECTED] wrote: I'm wondering what kind of graphics acceleration would be required to run flightgear at adequate speed. I have to admit that I haven't had time to try in months (I hope to get a bit of coding time soon as well as finishing other started bits - Spitfire). If it is anymore than a 32 MB graphics card for the simple stuff then I think that steps need to be taken to add a menu for graphics options if these are indeed configurable (and assuming the menu doesn't already exist). This menu would allow you to configure the game to run adequately on some defined baseline system. I would also like to see less reliance on command line options (I think this was getting better with xml driven menus when I last looked?) Finally can anyone tell me if they're looking at finding the bottlenecks in the code? Clarifying; points which slow it down which might be implemented in a different manner, not including possible small increases which I consider almost trivial. Some time ago I compiled everything with profiling (-pg) and more recently used oprofile, http://sourceforge.net/projects/oprofile/, to check for bottlenecks. IIRC ssgCullAndDraw() consumed the most time as would be expected for a graphics intensive app like FlightGear. I'm not aware of any profiling analysis in the past twelve months. Perhaps some effort should be put into examing working set usage and reducing the memory foot print. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C-GPTR ornithopter
On Tue, 10 Jun 2003 00:50:56 +0200 Frederic Bouvier [EMAIL PROTECTED] wrote: I had to apply the patch below to make it work. For an obscure reason, only the first assert is compiled, and the subsequent three tables are not allocated. So I removed the assert that don't seems very useful because you don't put assertions on the allocation of the other intermediate arrays. Asserting on memory allocations probably won't work anyway since new throws a std::bad_alloc exception. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [BUG]?input/keyboard:repeatabledependson cpu clock
On Wed, 04 Jun 2003 12:33:30 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: Norman Vine writes: Are you sure that's true? Yes ! The event queue still needs to check every event every iteration to see if anything is ready to run ... Not if the event queue is ordered by next run time ! All you have todo is process those items whose time stamp is less then when the queue traversal began and be sure that the queue remains ordered. What you describe would be an interesting/good way to impliment an event queue, but I believe the FlightGear event queue updates the time for each item, and then finds the one that is most ready to run (in other words, finds the most overdue event of all the runable events) and runs it. I believe Curt is correct re the current implementation; events are stored unordered and a sweep of the entire event queue is made per update. IIRC an earlier version was implemented like Norman's suggestion - events were prioritized according to time and only the item at the head of the queue needed to be checked each update. If greater use of events is required then the prioritized scheme would be preferable. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS gpsd
On Thu, 29 May 2003 14:11:06 -0400 Russell Nelson [EMAIL PROTECTED] wrote: You know what would be really neat? If flightgear's GPS support was able to emulate gpsd. So while you're flying around, you can run any mapping program that supports gpsd (gpsdrive or pygps at very least), and see your position as if you were there. A quick read of the gpsd protocol indicates it should be easy enough. A variation of the props server with some code from the NMEA protocol class should do the trick. I will code something this weekend if no one else wants to. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS gpsd
On Sat, 31 May 2003 09:13:09 -0400 David Megginson [EMAIL PROTECTED] wrote: Bernie Bright writes: A quick read of the gpsd protocol indicates it should be easy enough. A variation of the props server with some code from the NMEA protocol class should do the trick. I will code something this weekend if no one else wants to. You could also just rig up a bit of glue in Python or Perl, and call it fggpsd or something similar. Hadn't thought of that. The telnet style interface would be straight forward. The raw NMEA mode requires some extra thought but should be doable. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] controls-bind()
On Wed, 02 Apr 2003 10:58:21 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Gerhard Wesp wrote: strstream would do the trick, but not all compilers support it yet. Note that strstream is *deprecated* in C++, one should use stringstreams (sstream) instead. No danger of overflowing any buffers there. Cf. Josuttis, The C++ Standard Library, Section 13.11.2. AFAIK, every major platform now does have compilers which come sufficiently close to the standard to support sstream, or am I missing something? I was thinking of adding sstream to simgear/compatibility and define a HAVE_SSREAM in compiler.h, but unfortunatly even Boost doesn't provide a sstream replacement header. If we could find one, that might be the solution (to all our problems?) stringstream is fairly complex and depends on the underlying stream and string implementations. STLport has sstream but I doubt if it could be extracted as a stand alone file. Have you (Erik) tried STLport on your system? If it works then we probably wouldn't need the simgear compatibility stuff anymore. Note that MSVC6 does not have sstream while I think VC7 does. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] deprecated or antiquated header
On Thu, 27 Mar 2003 21:24:39 -0700 WillyB [EMAIL PROTECTED] wrote: Yes.. that was from TerraGear.. there are/were others from FG... but no idea how to change it so they are not there. I ran into this today... In file included from /usr/include/c++/3.2/backward/strstream:51, from uiuc_2DdataFileReader.h:6, from uiuc_2DdataFileReader.cpp:76: /usr/include/c++/3.2/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. StdC++ deprecates strstream in favor of sstream. Unfortunately not all compilers support the newer ostringstream and istringstream classes so we have to live with the warnings for now. On the other hand we could add a test for sstream to configure. Some code changes would also be required. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/misc sg_path.cxx,1.2,1.3sg_path.hxx,1.2,1.3
On Wed, 26 Feb 2003 13:50:17 -0600 Curtis L. Olson [EMAIL PROTECTED] wrote: Update of /var/cvs/SimGear-0.3/SimGear/simgear/misc In directory seneca:/tmp/cvs-serv25218/simgear/misc Modified Files: sg_path.cxx sg_path.hxx Log Message: Add some convenience functions to the SGPath function. Could the file(), dir(), base() and extension() functions be made const member functions. As it stands they cannot be applied to const reference/pointer values which limits their usefulness. Many thanks, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Undefined Symbols
On Tue, 18 Feb 2003 16:05:26 -0600 David Drum [EMAIL PROTECTED] wrote: [FlightGear-Devel readers: this is another installment in my quest to get FlightGear compiled under Mac OS X. I now have a good lead on the final link failure, I think. If you have any knowledge of linker naming conventions, symbol tables, and the like, I would appreciate your comments. Thanks. P.S. Everything is being built from CVS.] Previous make's were failing, unable to find gen_leaf or ssgVtxTable::ssgVtxTable. Sometime recently the call to gen_leaf was removed from the CVS code. Instead, three other symbols are now not being found. Here's the final make command along with output: david@Cynosure ~/FlightGear/src/main $ make g++ -DPKGLIBDIR=\/Users/david/lib/FlightGear\ -g -O2 -D_REENTRANT -L/Users/david/lib -L/usr/X11R6/lib -o fgfs main.o fg_commands.o fg_init.o fg_io.o fg_props.o fgfs.o globals.o logger.o options.o splash.o util.o viewer.o viewmgr.o location.o ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Autopilot/libAutopilot.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Scripting/libScripting.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/Network/libNetwork.a ../../src/NetworkOLK/libNetworkOLK.a ../../src/Objects/libObjects.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Environment/libEnvironment.a -lsgroute -lsgsky -lsgephem -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgdebug -lsgmagvar -lsgmisc -lsgxml -lsgserial -lsgthreads -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lplibpsl -lmk4 -lz -lpthread -lm -framework GLUT -framework OpenGL -framework Carbon -lobjc -lplibsl -lplibsm -framework IOKit -framework CoreFoundation -lm ld: warning table of contents of library: ../../src/FDM/JSBSim/libJSBSim.a not sorted slower link editing will result (use the ranlib(1) -s option) ld: Undefined symbols: trTileSize(_TRctx*, long, long, long) trImageSize(_TRctx*, long, long) trTileBuffer(_TRctx*, unsigned long, unsigned long, void*) ssgVtxTable::ssgVtxTable[in-charge](unsigned, ssgVertexArray*, ssgNormalArray*, ssgTexCoordArray*, ssgColourArray*) make: *** [fgfs] Error 1 I have been using nm to poke around and believe I know what is going on, even if I don't know how to fix it: david@Cynosure ~ $ nm -o lib/libsgscreen.a FlightGear/src/GUI/gui_funcs.o | egrep 'trTileSize|trImageSize|trTileBuffer' lib/libsgscreen.a:tr.o:1564 S _Z10trTileSizeP6_TRctxiii.eh lib/libsgscreen.a:tr.o:158c S _Z11trImageSizeP6_TRctxii.eh lib/libsgscreen.a:tr.o:01d4 T __Z10trTileSizeP6_TRctxiii FlightGear/src/GUI/gui_funcs.o: U __Z10trTileSizeP6_TRctxlll lib/libsgscreen.a:tr.o:03c8 T __Z11trImageSizeP6_TRctxii FlightGear/src/GUI/gui_funcs.o: U __Z11trImageSizeP6_TRctxll lib/libsgscreen.a:tr.o:036c T __Z12trTileBufferP6_TRctxjjPv FlightGear/src/GUI/gui_funcs.o: U __Z12trTileBufferP6_TRctxmmPv If you look closely at the T lines and the U lines, you will see that the symbol names do not match! No wonder the final link fails. I guess I need some way to get the compiler to generate the same symbol names. From simgear/screen/tr.h: extern void trTileSize(TRcontext *tr, GLint width, GLint height, GLint border); It looks like GLint is defined as an int when compiling SimGear but is long when compiling FlightGear. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Compile problem with Metakit
On Mon, 17 Feb 2003 10:24:01 +0100 [EMAIL PROTECTED] (Michael Basler) wrote: I have found the same problems. I think it is related to using gcc 3.2 on recent cygwin. Thanks, Richard, good to know it's not just my fault. gcc 3.2 doesn't look in /usr/local/* by default, so you need to add it manually (set CXXFLAGS and LDFLAGS appropriately). There must be a simpler and more automated solution, but my knowledge of the auto tools is insufficient to fix it. Curt, could you, please, fix this (shouldn't be hard for an expert, I guess...). There already is a --with-metakit=DIR option to configure. Conversely you specify CPPFLAGS and LDFLAGS on the command line to configure thus: CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dynamic Scenario's
On Mon, 10 Feb 2003 11:46:04 + David Luff [EMAIL PROTECTED] wrote: [snip] The limit of my ambition at the moment is to get light planes taxiing in and out of and flying circuits around GA airports at the moment. This is a huge amount of work in itself - particularly the taxiing part, which also involves writing an infrastructure to describe logical taxiway and parking networks at airports, and tools to allow users to create/modify them. There's absolutely no way I'm going to get time to do any planes that fly from one airport to another in the next year or so. I've been experimenting in this area too, particularly user tools. To that end I've added a taxiway editor to FGSD, FlightGear Scenery Designer, http://sourceforge.net/projects/fgsd. Data is saved to an xml file. The next step is to load this data into FlightGear and hook it into the ATC system. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dynamic Scenario's
On Mon, 10 Feb 2003 22:44:40 + David Luff [EMAIL PROTECTED] wrote: On 2/11/03 at 9:15 AM Bernie Bright wrote: On Mon, 10 Feb 2003 11:46:04 + David Luff [EMAIL PROTECTED] wrote: [snip] The limit of my ambition at the moment is to get light planes taxiing in and out of and flying circuits around GA airports at the moment. This is a huge amount of work in itself - particularly the taxiing part, which also involves writing an infrastructure to describe logical taxiway and parking networks at airports, and tools to allow users to create/modify them. There's absolutely no way I'm going to get time to do any planes that fly from one airport to another in the next year or so. I've been experimenting in this area too, particularly user tools. To that end I've added a taxiway editor to FGSD, FlightGear Scenery Designer, http://sourceforge.net/projects/fgsd. Data is saved to an xml file. The next step is to load this data into FlightGear and hook it into the ATC system. Fantastic! If it works then I'll abandon my efforts in that field immediately :-) The current data I've been reading in from KEMT.taxi is reproduced below: N 0 -118.0372167 34.08178333 0.0 J E-01-19 rwy 01 N 1 -118.0321833 34.0907 0.0 J E-01-19 rwy 19 N 2 -118.0369167 34.0817 0.0 H E N 3 -118.0318534.0906 0.0 H E N 4 -118.0351534.0848 0.0 T E N 5 -118.0349667 34.08511667 0.0 T E N 6 -118.0348333 34.0847 0.0 T E G 7 -118.0347333 34.0848 0.0 GS 10 N 8 -118.0346534.08498333 0.0 T E N 9 -118.0346 34.08456667 0.0 T E G 10 -118.0345167 34.0847 0.0 GS 10 N 11 -118.0344167 34.0849 0.0 T E A 0 1 R N A 0 2 T N A 1 3 T N A 2 4 T N A 4 5 T N A 3 5 T N A 4 6 T N A 6 9 T Y A 5 8 T Y A 8 11 T Y A 6 7 T Y A 7 8 T Y A 9 10 T Y A 10 11 T Y [End] N is a node, each one has a number, position, elev, code [J = junction, H = hold, T = T-junction], an E-code since denotes any runways that they are exits fom, and the node name. G is a gate, similar, but with a code for airplane - GS = GA single. A is an arc, this has the numbers of the two nodes it connects, a type [R = runway, T = taxiway], and [Y/N] to whether it is 2-way, and a name. Obviously there's more stuff that could go in here, such as weight limits on the arcs, but that's what I started with. Is this the sort of thing I can load from the xml output from your program? If so I guess I'd better take your xml file loader and plug it into the ATC system (ground.[ch]xx). Is your code in fgsd CVS yet? If not could you email it to me? My changes are not in cvs yet. I still have to implement undo/redo/delete functionality. However I will email you what I have so far. If you could bear to take a look at the brain-dump that masquerades for code in ground.[ch]xx perhaps you could have a look at my proposed node/arc structures and shout if you think I'm doing anything *really* silly before I get too far into it. I used your structures as a starting point. However the needs of the editor and the xml format forced some changes. But we are in the same ballpark. Here are some snippets from a KSFO taxiway file with some commentary: nodes node latitude type=double37.615023/latitude longitude type=double-122.356881/longitude nodetype type=stringNormal/nodetype /node node n=4 latitude type=double37.620940/latitude longitude type=double-122.370852/longitude nodetype type=stringHold/nodetype /node /nodes There are two types of nodes, Normal and Hold-Short. Unlike yours they don't contain an elevation but that shouldn't be too hard to add if required, it is available from the underlying fgsd tile/airport object. They also don't have your E-code or a name. I think these properties belong to the connecting arc/segment. gates gate latitude type=double37.615096/latitude longitude type=double-122.381158/longitude gatetype type=stringGateHeavy/gatetype radius type=double0.00/radius heading type=double0.00/heading /gate /gates There are 11 gate types for commercial, cargo, GA, military and seaplane aircraft. I haven't got around to inputting the radius and heading values yet, hence the zeros. segments segment type type=stringtaxiway/type node1 type=int0/node1 node2 type=int1/node2 name type=stringC/name width type=int110/width /segment segment n=55 type type=stringrunway/type node1 type=int35/node1 node2 type=int41/node2 name type=string10R/28L/name width type=int200/width /segment What you call
Re: [Flightgear-devel] Dynamic Scenario's
On Mon, 10 Feb 2003 22:17:27 -0600 Curtis L. Olson [EMAIL PROTECTED] wrote: Bernie Bright writes: [snip] Unlike yours they don't contain an elevation but that shouldn't be too hard to add if required, it is available from the underlying fgsd tile/airport object. Elevation is an interesting debate. If you include elevation in the logical road network, then you don't need to query the terrain for all you different objects as they move around. Terrain intersection querying is pretty expensive so that's a consideration. But, if you store elevation in the LRN, then there is a chance for any number of reasons that it could diverge from the actual terrain then you run the risk of cars flying through air and 747's driving underground and that can get pretty wierd too. Good point. The taxiway editor can get the node elevation from the underlying airport tile. Of course if the scenery is regenerated then the taxiways should be regenerated also. This may be no more than a load and save operation but currently must be performed manually. The other gotcha is that we would only know the elevation at either end of a segment. A vehicle travelling along the segment would still have to query the terrain engine. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dynamic Scenario's
On Mon, 10 Feb 2003 22:17:27 -0600 Curtis L. Olson [EMAIL PROTECTED] wrote: Bernie Bright writes: I used your structures as a starting point. However the needs of the editor and the xml format forced some changes. But we are in the same ballpark. Here are some snippets from a KSFO taxiway file with some commentary: nodes node latitude type=double37.615023/latitude longitude type=double-122.356881/longitude nodetype type=stringNormal/nodetype /node node n=4 latitude type=double37.620940/latitude longitude type=double-122.370852/longitude nodetype type=stringHold/nodetype /node /nodes There are two types of nodes, Normal and Hold-Short. Borrowing from my driving sim experience. The approach I've seen is that the logical road network is composed of nodes and roads. Any number of roads can intersect at a node. In addition, a road section can be composed of multiple points defining any sort of shape, curve, straight, or combination of that. Pretty much what I've done so far. Each road section can define a number of lanes (and their direction.) (Probably not needed for us) :-) Taxiway or runway are segment properties we would need to know. Some sort of width or weight property would be useful so that heavies don't try to taxi down a path not capable of handling them. You attach things like signal lights, gates, (hold short points?) to any of the sub points in a road section. Here is a link http://users.bigpond.net.au/bbright/fgsd.png to a screen dump of my current efforts. Taxiway F has been selected, highlighted in yellow. Red dots are hold-short nodes. Blue dots are normal nodes. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dynamic Scenario's
On Sun, 9 Feb 2003 17:59:52 + Paul Morriss [EMAIL PROTECTED] wrote: Hi, Is there any procedure for software documents etc? I have an outline of how I intend to write the software, I will start with other planes in the sky for now. Don't know about documentation but somebody (David Luff) has already started adding AI aircraft. Check under the src/ATC directory. Someone else is also working on turning the existing SimGear waypoint/route code into bona fide flightplans. Some coordination of efforts might be useful to split the workload and avoid duplication. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Class name clash and namespaces
On Wed, 22 Jan 2003 07:50:55 -0600
Jon Berndt [EMAIL PROTECTED] wrote:
Wouldn't something like this work?
Either:
using namespace jsbsim
or
using jsbsim::FGFDMExec
etc...
at the top of the files
or
fdmex = new jsbsim::FGFDMExec
etc...
everytime its needed.
Cheers - Dave
You would expect it to, wouldn't you. I added using namespace JSBSim at
the top of JSBSim.hxx as follows:
/*
%%
FORWARD DECLARATIONS
%%
*/
#include simgear/misc/props.hxx
#include FDM/JSBSim/FGFDMExec.h
using namespace JSBSim;
class FGState;
class FGAtmosphere;
class FGFCS;
class FGPropulsion;
class FGMassBalance;
class FGAerodynamics;
class FGInertial;
class FGAircraft;
class FGTranslation;
class FGRotation;
class FGPosition;
class FGAuxiliary;
class FGOutput;
class FGInitialCondition;
But, I get this when I try and compile:
g++ -DHAVE_CONFIG_H -I. -I. -I../../../src/Include -I../../.. -I../../../s
rc -DFGFS -c -o JSBSim.o `test -f 'JSBSim.cxx' || echo './'`JSBSim.cxx
In file included from JSBSim.cxx:63:
JSBSim.hxx:218: syntax error before `*'
JSBSim.hxx:221: syntax error before `*'
JSBSim.hxx:222: syntax error before `*'
JSBSim.hxx:223: syntax error before `*'
JSBSim.hxx:224: syntax error before `*'
JSBSim.hxx:225: syntax error before `*'
JSBSim.hxx:226: syntax error before `*'
JSBSim.hxx:227: syntax error before `*'
JSBSim.hxx:228: syntax error before `*'
JSBSim.hxx:229: syntax error before `*'
JSBSim.hxx:230: syntax error before `*'
JSBSim.hxx:231: syntax error before `*'
JSBSim.cxx: In method `FGJSBsim::FGJSBsim(double)':
JSBSim.cxx:81: parse error before `='
JSBSim.cxx:82: `Atmosphere' undeclared (first use this function)
JSBSim.cxx:82: (Each undeclared identifier is reported only once
JSBSim.cxx:82: for each function it appears in.)
JSBSim.cxx:83: `FCS' undeclared (first use this function)
JSBSim.cxx:84: `MassBalance' undeclared (first use this function)
...
...
Forward declarations must be in a namespace:
namespace JSBSim {
class FGState;
class FGAtmosphere;
class FGFCS;
class FGPropulsion;
class FGMassBalance;
class FGAerodynamics;
class FGInertial;
class FGAircraft;
class FGTranslation;
class FGRotation;
class FGPosition;
class FGAuxiliary;
class FGOutput;
class FGInitialCondition;
}
using namespace JSBSim;
...
Just updated my FlightGear JSBSim sources with namespace versions and am happy
to announce a clean compile.
Cheers,
Bernie
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Remote root exploit found in CVS
Slashdot reports that CVS versions 1.11.4 and lower can grant root access to malicious remote users. They advise anyone running a cvs server to upgrade to 1.11.5 ASAP. You have been warned. Bernie http://developers.slashdot.org/developers/03/01/21/1752251.shtml?tid=128 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: New Menu Bar; dialogs for clouds,winds, and air
On Sat, 18 Jan 2003 12:39:32 -0500 David Megginson [EMAIL PROTECTED] wrote: The new XML-configured menubar is now the default for FlightGear; configure --with-old-menubar to get the old one (which I'll keep around for now, until we're sure the new one is working OK). Please, everyone, give the new menubar a spin, and take a look at $FG_ROOT/gui/menubar.xml and $FG_ROOT/gui/dialogs/*.xml to see how to add new menu entries and dialogs. As an example, I've added a Weather menu with the ability to set winds, temperature/pressure/dewpoint, and cloud layers. The weather dialogs are not found unless the FG_ROOT environment variable is set. Shouldn't this really be globals-get_fg_root() ? Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] KSFO International Terminal
On Fri, 17 Jan 2003 16:25:10 -0500 David Megginson [EMAIL PROTECTED] wrote: Major A writes: It now works fine, thanks a lot! I like the terminal building at KSFO... You get the prize for being the first to notice -- congrats (I sneaked it into the base package CVS fairly quietly). It's just a roughing-in of the new International Terminal, but I'll try to fill in the others as soon as I can find pictures of them. Maybe I should park a copy of the 747 at the terminal for now. I guess we'll also need windsocks and taxiway signs. I noticed too because it conflicted with my imported XPlane terminal! If you are interested I have an overhead shot of KSFO. You can't see taxiway signs or windsocks but it does show the relative positioning of the terminal, gates, hangars and other ancillary buildings. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaced thresholds (was: RE:[Flightgear-devel] Roadmap/brain dump)
On Wed, 15 Jan 2003 01:45:30 + David Luff [EMAIL PROTECTED] wrote: [snip] ... FWIW I'm currently writing a program to allow the laying out of a logical taxiway and parking place network for AI planes to follow over an image of Flightgear's rendered taxi and runways by clicking on it where intersections etc are wanted. The FS2002 crowd have a freeware utility called AFCAD that performs a similar task. It produces a structured text output file. If we could import such a file then we could leverage a lot of existing taxiway maps for AI traffic. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Threaded file loader and MSVC ?
On Mon, 13 Jan 2003 02:02:30 +0100 Michael Pujos [EMAIL PROTECTED] wrote: Hi I built with VC++ 6.0 FlightGear 0.9.1 with pthread support for the tile loader using pthread-win32 2002-11-04 At execution an assert fails in SGMutex::unlock(). So my question is if anyone had this working ? Or does it work only built with cygwin ? Is it stable and does it work well ? I'm currently experimenting with native win32 thread support. Initial tests are hopeful although I haven't fully implemented mutexes or conditions yet. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] build identification
On Mon, 6 Jan 2003 22:55:56 -0600 Jon Berndt [EMAIL PROTECTED] wrote: I found it very helpful to capture a compile date and cvs tag into a chip design that verification people could use to direct me to a particular verilog code base to reproduce and debug problems. Good idea. We sort of do this for JSBSim. Isn't there a command that you can type to get information on an executable? I can do something like this: strings jsbsim.exe | grep Id and get a list of all the modules and version/date information that went into the executable. That doesn't get the compile info, but it is a start. Aren't there compiler-defined variables that could go into a version string which could be displayed when someone typed: fgfs --version ?? The very first thing FG displays is its version number and compiler info: [bbright@proton Main]$ ./fgfs FlightGear: Version 0.9.1 Built with GNU C++ version 3.2 Scanning command line for: --fg-root= ... It would be trivial to add a timestamp. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] strstream issues
On Tue, 31 Dec 2002 16:16:44 +0100 Erik Hofman [EMAIL PROTECTED] wrote: Hi, while browsing around I found the following piece of info: strstream considered harmful [snip] I noticed there are some places that use strstream. Should we depreciate the use of it for FlightGear? That would be nice except that not many compilers support the newer sstream alternative, gcc-2.95.x among them. I think we just have to live with the current situation and be very careful with our usage of the strstream class. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC Sound
On Tue, 31 Dec 2002 22:10:31 -0600 Curtis L. Olson [EMAIL PROTECTED] wrote: Erik Hofman writes: David Megginson wrote: [EMAIL PROTECTED] writes: FWIW, I found 1 a bit quiet, although audiable over the idling engine, so I set it to 2, which was audiable over the full throttle engine. Thats on windows though, although I could certainly make it out over the idling engine when I tested on Linux at 2. Hmm. I wonder what the issue is. At 10, I can hear, perhaps, 75% of it over the idling engine, but I still have to strain to make it out. It's also a matter of what you want to simulate. I think up until now we simulate the situation where the pilot doesn't wear headphones. With ATC that is becoming inpractical. So it might be time to tune down engine, squeel, noise at all. Anyone have any thoughts about how we might be able to simulate two separate and distinct audio output streams? One for the ambient cockpit noise, and one for the headphone noises? OpenAL? I know Steve Baker @ plib was keen to add some sort of ssgAudio node using OpenAL. It does introduce yet another dependency though. Could be a great little sub-project for someone to run with. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Updates for simgear_config.h.vc5
This patch adds GLUT_H and updates PACKAGE and VERSION. === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/simgear_config.h.vc5,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 simgear_config.h.vc5 --- simgear_config.h.vc57 Sep 2002 02:58:19 - 1.1.1.1 +++ simgear_config.h.vc51 Jan 2003 06:39:28 - @@ -1,5 +1,7 @@ /* Include/config.h. Generated for MSCV++ 5.0 */ +#define GLUT_H GL/glut.h + /* Define if the X Window System is missing or not being used. */ #define X_DISPLAY_MISSING 1 @@ -13,7 +15,7 @@ #define HAVE_VPRINTF 1 /* Define to package name */ -#define PACKAGE FlightGear +#define PACKAGE SimGear /* Define as the return type of signal handlers (int or void). */ #define RETSIGTYPE void @@ -31,7 +33,7 @@ /* #define TM_IN_SYS_TIME 1 */ /* Define to version number */ -#define VERSION 0.0.8 +#define VERSION 0.3.1 /* Define if compiling on a Winbloze (95, NT, etc.) platform */ #define WIN32 1 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/compatibility - Newdirectory
On Mon, 30 Dec 2002 15:32:53 -0600 David Megginson [EMAIL PROTECTED] wrote: Update of /var/cvs/SimGear-0.3/SimGear/simgear/compatibility In directory seneca:/tmp/cvs-serv31511/simgear/compatibility Log Message: Directory /var/cvs/SimGear-0.3/SimGear/simgear/compatibility added to the repository Getting the following error trying to cvs update: cvs server: Updating simgear/compatibility cvs server: failed to create lock directory for `/var/cvs/SimGear-0.3/SimGear/simgear/compatibility' (/var/cvs/SimGear-0.3/SimGear/simgear/compatibility/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/var/cvs/SimGear-0.3/SimGear/simgear/compatibility' cvs [server aborted]: read lock failed - giving up This is on Mandrake 9.0 using cvs 1.11.2. I think this could be due to ownership/permission problems in the cvs repository. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] properties documentation
On Fri, 27 Dec 2002 16:08:30 -0600 Mike Bonar [EMAIL PROTECTED] wrote: I am currently experimenting with doxemacs, a lisp extension to emacs that aids in formatting code for use with doxygen. Being an emacs newbie this might take a few days to get working ;-) I'll upload samples for everyone to see shortly. In the meantime, here are a couple of sites that have got doxygen working well. They show the kinds of things we can include if we want. Regards, Mike http://wbxmllib.sourceforge.net/html/index.html http://www.focus-sw.com/doc/FTMP_MBCC/ http://bakery.sourceforge.net/reference/html/index.html http://www.simgear.org/doxygen/index.html Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Subversion Vs. CVS
On Tue, 24 Dec 2002 10:38:41 +0100 Erik Hofman [EMAIL PROTECTED] wrote: Hi, Today I read about subversion on the OpenBSD magizine site. http://subversion.tigris.org/ Subversion is meant to be a better CVS, so it will have most of CVS's features, with as many as possible in the 1.0 release. The main exception is svn blame (i.e., cvs annotate), which has been put off until after 1.0 for scheduling reasons. Generally, Subversion's interface to a particular feature is similar to CVS's, except where there's a compelling reason to do otherwise. I think it might be worth looking at for FlightGear, SimGear, TerraGear and the base package. Theres also bitkeeper http://www.bitkeeper.com/ and arch http://www.regexps.com/ (this link seems to be dead at the moment). Note that BK is not open source but is available free for non-commercial use. All Linux kernel development now uses BK, read the thread at http://gcc.gnu.org/ml/gcc/2002-12/msg00800.html for Linus' views of BK vs CVS. Personally I'd prefer BK instead of yet another cvs clone but then again do we really need to change revision control systems at all? Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build Problem with MSVC 6.0
On Fri, 20 Dec 2002 20:02:51 -0800 Jonathan Polley [EMAIL PROTECTED] wrote: I finally get my ISP straightened out and was able to update to CVS again (Ya!). Unfortunately, I came across a couple of problems. First, the macro GLUT_H does not seem to be defined anywhere. Where is that suppose to be (I stuck it in the appropriate config.h)? GLUT_H should be added to simgear_config.h.vc5. This file is copied to simgear_config.h by the supplied workspace file. Also note that the PACKAGE and VERSION macros should be changed to SimGear and 0.3.1 respectively. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear-cvs compile error (cygwin gcc-3.2)
On Wed, 27 Nov 2002 13:41:58 -0500 Norman Vine [EMAIL PROTECTED] wrote: William Earnest writes: Norman Vine wrote: ace project writes: I'm getting a compile error while compiling the latest SimGear(CVS) under cygwin(current version/fresh install). extgl.h:363: `glBlendColor' redeclared as different kind of symbol /usr/X11R6/include/GL/gl.h:1648: Looks like you have 'X-Windows' installed If this is true AFAIK you are breaking new ground and the configure scripts will need to be tweaked to suport this. I'm in a similar position, but possibly a bit further along. Have a current Cygwin installation including their X windowing package. Also have the current CVS of the development package. By going to /usr/X11R6/include/GL/ and renaming (to hide without losing) gl.h and glext.h, then restarting with ./configure, the compiles all completed without error (but many warnings). YIKES -- The *right* way todo this is to just change the configure.ac files to NOT check for 'X' and NOT include the X_Header path when WIN32 is defined. Doesn't --without-x disable the checks for X headers and libraries? Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Built-in Commands
On Sat, 26 Oct 2002 07:29:30 -0400 David Megginson [EMAIL PROTECTED] wrote: Bernie Bright writes: There was a discussion some months ago about adding command properties, that is, tying a property to a command such that writing to the property triggers the command. Such commands then become available to external scripts as well as the binding interface. Should we investigate this further? The alternative is to make the commands available through the external interface as well. Let's develop some examples and use cases and see which works best -- I'm not strongly prejudiced either way. I tried adding commands to the props/telnet interface but it was agreed it was better to add them as properties so they would be available to all external interfaces. As an example, I added the following to fgInitCommands(): typedef bool (*dummy)(); fgTie( /command/view/next, dummy(0), do_view_next ); fgTie( /command/view/prev, dummy(0), do_view_prev ); The implementation of void do_view_next(bool) and void do_view_prev(bool) is essentially the same as the existing do_view_cycle(). As a further test I added a new key binding to keyboard.xml: key n=86 nameV/name descPrev View/desc binding commandproperty-assign/command property/command/view/prev/property value type=booltrue/value /binding /key So now V and Shift-V cycle forwards and backwards through the available views. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Built-in Commands
On Fri, 25 Oct 2002 21:20:56 -0400 David Megginson [EMAIL PROTECTED] wrote: I've simplified the SimGear command-manager interface a little further, and have added a README in docs-mini for binding new commands in FlightGear. It's so short that I can include it verbatim here: There was a discussion some months ago about adding command properties, that is, tying a property to a command such that writing to the property triggers the command. Such commands then become available to external scripts as well as the binding interface. Should we investigate this further? Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bugzilla
On Tue, 15 Oct 2002 23:02:09 +1000 David Findlay [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Has anyone thought of using bugzilla to keep track of bugs and suggestions for FlightGear? If no one else wants to, I could administer it, since I seem to have no time to code these days. Thanks, David We already have that facility on sourceforge but its hardly ever used. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] STL and vectors (final?)
On Tue, 8 Oct 2002 00:16:24 -0700 ace project [EMAIL PROTECTED] wrote: --- Bernie Bright [EMAIL PROTECTED] wrote: On Mon, 7 Oct 2002 08:09:32 -0400 Norman Vine [EMAIL PROTECTED] wrote: ace project writes: vector_of_elements.erase(vector_of_elements[index]); I think your are making the too rapid assumption that an iterator is a pointer to an element. Thats the one I ment Fred (my mistake). It works for me (while I don't know whether is *really* correct). FWIW - I think the intended method of the 'standard' writers is vector.erase( vector.at( index ) ); but not all C++ implementations have the 'conforming' at() method. AFA IK - at() is in Microsoft V6 and V7 and g++3.X Note a conforming vectorT. at(index) method performs a range check on 'index' and throws a std::out_of_range exception if index is out of range. Has anyone suggested vector.erase( vector.begin() + index ) This looks dangerous, I not sure whether vector implements a operator+ function (mine does NOT). So in mine case I would try to erase a element with address vector.begin()+index, which would not do anything except maybe throw a nasty segfault, since the chances that a element exists with that address is slim. Should be perfectly safe as long as index vector.size(). There is no vector operator+ but thats not what is called. vector.begin() returns a (random access) iterator that we increment to point to the desired element. [snip] Just use this code, it guaranteed valid until something invokes vector.resize() (implicit or explicit) vector_of_elements.erase(vector_of_elements[index]); //range NOT checked or vector_of_elements.erase(vector_of_elements.at(index)); //range CHECKED Both of these fail to compile with gcc 3.2 because vector::erase() requires one or two iterator arguments. Neither vector::operator[] nor vector::at() return an iterator. I think it works(dont sue me if I'm wrong) because vector_of_elements[index] returns a reference to a element, which can be transformed to a pointer for use by erase(). The [] subscripting operator used here is NOT the same as used by a basic array, thus not just a pointer to sizeof(elements)*index) but a overwritten operator (user implemented). Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] STL and vectors
On Mon, 7 Oct 2002 07:36:53 -0400 David Megginson [EMAIL PROTECTED] wrote: Frederic Bouvier writes: Or should it be : vector_of_elements.erase(vector_of_elements[index]); I think your are making the too rapid assumption that an iterator is a pointer to an element. Don't iterators override the '+' operator if they're not just pointers? Only random access iterators support the '+' operator. Fortunately std::vector and std::deque provide just such iterators. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] STL and vectors
On Mon, 7 Oct 2002 08:09:32 -0400 Norman Vine [EMAIL PROTECTED] wrote: ace project writes: vector_of_elements.erase(vector_of_elements[index]); I think your are making the too rapid assumption that an iterator is a pointer to an element. Thats the one I ment Fred (my mistake). It works for me (while I don't know whether is *really* correct). FWIW - I think the intended method of the 'standard' writers is vector.erase( vector.at( index ) ); but not all C++ implementations have the 'conforming' at() method. AFA IK - at() is in Microsoft V6 and V7 and g++3.X Note a conforming vectorT. at(index) method performs a range check on 'index' and throws a std::out_of_range exception if index is out of range. Has anyone suggested vector.erase( vector.begin() + index ) yet? Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] STL and vectors
On Mon, 07 Oct 2002 09:53:09 -0700 Andy Ross [EMAIL PROTECTED] wrote: Bernie Bright wrote: Only random access iterators support the '+' operator. Fortunately std::vector and std::deque provide just such iterators. I thought there was a variant that supported incrementation but not decrementation. You don't need the full-on random access variant in this case. That's defined as supporting the '[]' operator; '+' is useful without random access (walking a linked list, for example). Maybe you're thinking of the ++ and -- operators. All iterator categories support the ++ operator, bidirectional and random access iterators add support for pre and post decrement, and random access iterators support iterator arithmetic. There is also the advance(iter,n) function that provides some additional random-access-like capabilites. But I digress. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Startup seg fault
On Thu, 3 Oct 2002 20:52:54 -0700 John Wojnaroski [EMAIL PROTECTED] wrote: With the latest CVS for SimGear and FG (updated 20:00 PDT) seeing Unable to detect the current language ./test: line 5 9148 Segmentation fault yada yada yada Wasn't paying attention to the discussions on internationalization -- did I miss something? Base package was updated as of 03Oct02 02:01:31 EDT. Is CVS racing ahead of the base package? Had the same problem. Updating the base package fixed it. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Startup seg fault
On Fri, 04 Oct 2002 01:51:32 -0400 John Check [EMAIL PROTECTED] wrote: On Thursday 03 October 2002 11:52 pm, John Wojnaroski wrote: With the latest CVS for SimGear and FG (updated 20:00 PDT) seeing Unable to detect the current language ./test: line 5 9148 Segmentation fault yada yada yada Wasn't paying attention to the discussions on internationalization -- did I miss something? Base package was updated as of 03Oct02 02:01:31 EDT. Is CVS racing ahead of the base package? Regards John W Not to my knowledge. I'm having a problem building Simgear myself I got a compilation error concerning cout and endl. Commenting out the offending line fixed it. Bernie PS This is on Mandrake 9.0 with gcc3.2. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC 6.0 Problem with systems/vacuum/vacuum.cxx
On Tue, 24 Sep 2002 03:46:54 -0400 Norman Vine [EMAIL PROTECTED] wrote: Bernie Bright writes: On Mon, 23 Sep 2002 18:51:25 -0700 Jonathan Polley [EMAIL PROTECTED] wrote: MSVC does not have fmin() defined, so complains in vacuum.cxx. gcc 2.95.3 complains too. fmin() is only defined if _ISOC99_SOURCE is defined before including math.h. I wonder if we are going to need a sg_math.h if so here is a first stab at one [cut] Well, as far as I can tell, fmin() is C99 not Std C++. We could use std::min() but that causes a problem with MSVC where you have to use cpp_min() instead. And so it goes on... Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Shared Scenery Objects
On Sun, 22 Sep 2002 07:53:34 -0400
David Megginson [EMAIL PROTECTED] wrote:
For a while now, FlightGear has had support for adding static scenery
objects (like buildings) to *.stg scenery files using the syntax
OBJECT_STATIC file lon lat elevation-m heading
The file is always loaded relative to the current scenery directory
(such as /usr/local/scenery/w080n40/w077n45), which is great for
one-off objects like the Golden Gate Bridge or the Empire State
Building, but not so useful for objects like radio towers, barns,
etc. that can be used over and over.
I have just added a new directive, OBJECT_SHARED, that works exactly
like the above except that it loads the object relative to $FG_ROOT
rather than the current scenery directory. For example, I have my
$FG_ROOT at /usr/local/FlightGear/ and my $FG_SCENERY at
/usr/local/Scenery. If I add this line to w080n40/w077n45/1696211.stg
OBJECT_STATIC red-barn.ac -76.022499 45.319500 200 0
FlightGear will attempt to load
/usr/local/Scenery/w080n40/w077n45/red-barn.ac
On the other hand, if I have
OBJECT_SHARED Models/Buildings/red-barn.ac -76.022499 45.319500 200 0
FlightGear will attempt to load
/usr/local/FlightGear/Models/Buildings/red-barn.ac
Excellent! Hopefully this will work for texture files referenced by the object. FWIW
I'm working on importing XPlane custom objects and many of them share textures. I
already have the SFO terminal and Golden Gate bridge loading.
The big challenge right now is figuring out what tile to add an object
to -- I will try to whip up a Perl script to help with this. Once
that's working, we can automatically add all NDB towers and VOR
transmitters from our current data and populate the world a little
more; one user has a copy of the FAA obstacle database, and that would
allow us even more detail in the U.S.
The following c++ program prints the tile name given a lat/lon.
[bbright@proton FlightGear-0.7]$ cat latlon.cxx
#include iostream
#include cstdlib
#include simgear/bucket/newbucket.hxx
using std::cout;
int
main( int argc, char* argv[] )
{
if (argc != 3)
{
cout Usage: argv[0] lat lon\n;
return 1;
}
double dlat = atof( argv[1] );
double dlon = atof( argv[2] );
SGBucket b( dlon, dlat );
cout b.gen_base_path() / b.gen_index_str() \n;
return 0;
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Shared Scenery Objects
On Sun, 22 Sep 2002 11:00:18 -0400 David Megginson [EMAIL PROTECTED] wrote: It would be nice to set them up as a separate download, but we will need these in the base package soon, so unless the author is willing to change the terms, we'll have to reproduce them outselves. I think that we need to add the Bay-area bridges before anything else; next could be a few obvious landmarks like the Cow Palace, the TransAmerica building, and Alcatraz, then the KSFO terminal buildings. The package I downloaded includes the following bridges: ggbridge - Golden Gate wobbridge eobbridge smbridge srbridge tnbridge dunbridge I'm not familiar with the names or positions of the Bay-area bridges but hopefully this includes them all. The package contains terminals for Oakland and Seatac. It also contains generic control towers, hangars, buildings, a prison and the space needle. I will contact the author and see if he will allow us to repackage some of these objects and textures under a different, compatible, license. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Removed simgear/interpreter/
On Wed, 18 Sep 2002 15:39:11 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: David Megginson writes: I've updated configure.ac, but have not changed SimGear.dsp (an MSVC thing?). If someone who uses this file can send me a patched version, I'll commit it ASAP. The MSVC work spaces are generated automatically whenever I run make dist. I have taken care of this. I'm not sure if the am2dsp perl script will work any longer since we've changed to configure.ac. Am2dsp is just automake modified to generate dsp and dsw files instead of Makefile.am. If and when time allows I'll modify it to use the new regime. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Bug in uiuc_menu.cpp
The function void d_1_to_1(double array1[100], double array2[100] ) passes an incorrect size to memcpy. The correct value should be 100*sizeof(double) since sizeof(array2) is actually sizeof(double*). Alternatively the size could be passed as a parameter effectively making d_1_to_1 a pointless wrapper around memcpy. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] I have a Saitek Cyborg 3D Gold USB Stick
On Sun, 14 Jul 2002 07:33:46 -0400 David Megginson [EMAIL PROTECTED] wrote: Victoria Welch writes: As for jscal, I am unable to locate it for mandrake. The source I found (which seems to have been an early version ?!?!?!?!) wants to be compiled into the kernel and I find that just too odd. I'm very surprised that this is not a standard part of Mandrake, because I've heard many people who like that distro. If it's not, perhaps your life would be easier if you switched to another distro, because there must be many other things missing as well -- several FlightGear developers use Debian, which is beautifully simple to maintain and update but slightly harder to install than RedHat. When you read about a new program and want to try it, it's usually as easy as apt-get install whatever For whatever reason Mandrake doesn't include jscal or jstest. However these are part of the joystick package which can be downloaded from your local cooker mirror. Alternatively you can download the linuxconsole package from sourceforge. jscal and jstest are in the ruby/utils directory. Cheers, Bernie (a happy Mandrake 8.2 user) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] I have a Saitek Cyborg 3D Gold USB Stick
On 14 Jul 2002 09:02:50 -0700 Victoria Welch [EMAIL PROTECTED] wrote: Hi Tony, Thanks for the response! On Sun, 2002-07-14 at 08:39, Tony Peden wrote: rpmfind lists this: http://www.rpmfind.net//linux/RPM/cooker/contrib/RPMS/joystick-1.2.15-1mdk.i586.html Unfortunately Mandrake 8.2 comes with the 2.1.0 driver (where that exists, I have not a clue) and the 1.2.15 stuff will not run with the version I have . Thats unfortunate. I have successfully downloaded and compiled jscal from http://sourceforge.net/projects/linuxconsole/. Of course the force feedback stuff I'm playing with doesn't want to work but you can't have everything. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Engine project started
On Mon, 24 Jun 2002 12:21:46 -0700 ace project [EMAIL PROTECTED] wrote: [snip] The first important decision now is, do we multi-threading or multiplexing-IO ? For multiplexing, PLIB can be used. For multi-threading, we got a problem. Another issue is how to get the code to compile on other platforms, because threading and sockets aren't 100% portable, to say the least. PLIB's socket library is reasonably portable. It runs on every platform that FlightGear runs on. There are many portable open source threading libraries available, Boost.Thread, ZThread and CommonC++ to mention just a few. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Telnet interface don't send proper line endings on windows
Frederic Bouvier wrote: As we discussed in the list, line endings don't depends on the platform where the server or the client is run. But the patch is imcomplete : The help command is OK but the dump command still send only LF as line endings. In fact, my patch missed that point too. writeProperties is used to dump a node but the simgear version only produce LF. Hmmm. I suppose writePropertes() could be modified to take a line terminator argument that defaults to \n. On the other hand the dump command produces valid xml as is. As long as its readable by an xml parser we shouldn't have to change anything. Perhaps we should think of dump as producing binary output thats not fit for human consumption. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Win32 Source code
A J wrote: Hi all Is there any flight gear source code for visual c++ 6.0 if there exist please send me its address FlightGear supports MSVC6. Workspace and project files are included in the source. Visit the FlightGear web page at http://www.flightgear.org/ for download instructions. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] easter egg!!
Wondered why the sudden increase in network traffic when starting FlightGear just now. Then heard the new intro theme. Cute! Very cute! Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Bad line endings when running on windows
Frederic Bouvier wrote: From: Melchior FRANZ [EMAIL PROTECTED] * Bernie Bright -- Sunday 19 May 2002 06:23: As for line endings I think its simpler if we just use CRLF for both client and server. I will check that the new server always sends CRLF. ACK Not that this is in any way obligatory, but the perl documentation says: $ man perlipc|col -b|grep -A12 Line Terminators Internet Line Terminators The Internet line terminator is \015\012. Under ASCII variants of Unix, that could usually be written as \r\n, but under other systems, \r\n might at times be \015\015\012, \012\012\015, or something completely different. The standards specify writing \015\012 to be conformant (be strict in what you provide), but they also recommend accepting a lone \012 on input (but be lenient in what you require). We haven't always been very good about that in the code in this manpage, but unless you're on a Mac, you'll probably be ok. This is off-topic. As Julian points out, RFC854, chapter 7, specify that a new line is CRLF in the telnet protocol. We are not bound to implement the telnet protocol because we don't provide a telnet server. However you are correct in that the props server doesn't always respond with CRLF line terminators. I have a patch that I will send to Curt real soon. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bad line endings when running on windows
Frederic Bouvier wrote: The telnet interface produce wrong line ending when I run both FlightGear and the telnet client on Win2k. I've just sent a patch to Curt that produce line ending based on the platform where fgfs is running ( something between #ifdef and #endif ). For the moment, this patch only address the issue when fgfs and the telnet client run on the same platform. Thinking of it now, it would be better to generate proper line endings based on the capabilities of the client. Do the telnet interface support telnet commands DO, DONT, WILL and WONT ? or perhaps line ending can be deduced from the incoming command. Just a word of warning: there are currently two telnet servers in FlightGear. The original --props server and the new --telnet server. I haven't had time to combine them into a single server yet. Neither server implements telnet's option negotiation. The fact that you can connect to them with a telnet client doesn't make them telnet servers. You can connect to nntp, ftp, smtp and pop3 servers with a telnet client too. As for line endings I think its simpler if we just use CRLF for both client and server. I will check that the new server always sends CRLF. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest Update Problems
Julian Foad wrote: Jonathan Polley wrote: Two other things. First there is a constant string in telnet.cxx that contains CRs, which MSVC does not like. Second, telnet.cxx uses snprintf(), which is not supported under MSVC (for some reason, they use _snprintf(), go figure). I think the reason is that snprintf is not a standard (i.e. ANSO/ISO standard library) function and a standard-conforming compiler should not introduce non-standard names into the user's name space (names starting with _ are reserved for this sort of purpose). Anyway, I agree with Bernie's request that it should be #defined in the compiler.h. For the record snprintf() is part of the C99 standard. Anyways I've submitted a patch for Curt to commit. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] the new telnet server and scripting
Curtis L. Olson wrote: First, let me point out the new telnet server is *very* nice. Bernie has rewritten it based on the plib net libs. It can handle multiple concurrent connections. This is a big improvement! I'm not sure why you would need to run two or more sessions but there you go. The server design is based on Curt's httpd classes so I can't take full credit. Along with this, Bernie has also provided a demo python script that shows how you can use the telnet interface to remotely interact with and control a FlightGear application. In the cvs source (run cvs update -d of course) look in $toplevel/scripts/python for the demo script. So, to try this out run: fgfs --telnet=5500 python demo.py Then watch the action. This is a demo of functionality so you aren't going to see any earth shattering visual effects. But, it's very cool from the geeky perspective of running an external script which has complete control over flightgear. The python code is very experimental, really just proof of concept stuff. I was just toying around seeing how to use the props interface. I was thinking that this concept could be developed into a full blown demostration for exhibitions. A takeoff, circuit and landing, complete with cut-aways to external views, zooms and pans, all under script control would be really cool. Bernie, on the subjects of building additional commands into the telnet interface, I agree with Melchior. I'd rather not see the telnet interface being crammed with a bunch of extra commands that only the telnet interface knows about. I haven't looked at this in a while, but the property manager should be able to manage commands as well as values. The command management is a bit of a hack (kind of but not really) but since we can tie variables to funtions (usually getters and setters) we can expose additional functionality through the property interface. I think that would be the more appropriate way to do this and to develop additional commands. This way, these commands will be available (and consistant) for any other interface mechanisms including joystick, keyboard, mouse in addition to remote scripts or web browsers, etc. I don't have a complete handle on the property system yet. However if we can do these sort of things through properties and/or the command manager then that is definitely the way to go. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] the new telnet server and scripting
Curtis L. Olson wrote: [snip] Bernie, on the subjects of building additional commands into the telnet interface, I agree with Melchior. I'd rather not see the telnet interface being crammed with a bunch of extra commands that only the telnet interface knows about. I haven't looked at this in a while, but the property manager should be able to manage commands as well as values. The command management is a bit of a hack (kind of but not really) but since we can tie variables to funtions (usually getters and setters) we can expose additional functionality through the property interface. I think that would be the more appropriate way to do this and to develop additional commands. This way, these commands will be available (and consistant) for any other interface mechanisms including joystick, keyboard, mouse in addition to remote scripts or web browsers, etc. Bear with me while I get up to speed with the property system but I'm just brainstorming... Assuming we create some write-only properties that are tied to commands. Perhaps something like: /command/view/next /command/view/prev Writing a value to /command/view/next switches to the next view. Now this functionality duplicates the view-cycle builtin command so I'm wondering if should combine these two concepts? Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest MSVC Problem with options.cxx
Curtis L. Olson wrote: Jonathan Polley writes: MSVC does not like the size of the string constant in options.cxx C:\FlightGear\src\Main\options.cxx(1143) : error C2026: string too big, trailing characters truncated C:\FlightGear\src\Main\options.cxx(1181) : error C2026: string too big, trailing characters truncated C:\FlightGear\src\Main\options.cxx(1215) : error C2026: string too big, trailing characters truncated Bernie, Maybe we need to chalk this up as a really nice idea that didn't quite work out as well as we hoped. [Darned MSVC] :-) Who wants to do the honors of reverting back to the original code? I've reverted options.cxx to the previous version and am recompiling. Expect an update soon. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest Update Problems
Jonathan Polley wrote: Two other things. First there is a constant string in telnet.cxx that contains CRs, which MSVC does not like. Second, telnet.cxx uses snprintf(), which is not supported under MSVC (for some reason, they use _snprintf(), go figure). Could we fix the snprintf/_snprintf problem once and for all by adding #define snprintf _snprintf to simgear/compiler.h in the MSVC section. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Navaids fix.hxx,1.6,1.7ils.hxx,1.16,1.17 nav.hxx,1.22,1.23
Erik Hofman wrote: David Megginson wrote: Update of /var/cvs/FlightGear-0.7/FlightGear/src/Navaids In directory seneca:/tmp/cvs-serv23071/src/Navaids Modified Files: fix.hxx ils.hxx nav.hxx Log Message: Mac OS X patches from Jonathan Polley. *** 37,41 #elif defined( SG_HAVE_NATIVE_SGI_COMPILERS ) # include iostream.h ! #elif defined( __BORLANDC__ ) # include iostream #else --- 37,41 #elif defined( SG_HAVE_NATIVE_SGI_COMPILERS ) # include iostream.h ! #elif defined( __BORLANDC__ ) || (__APPLE__) # include iostream #else I think we should make more use of the STL_* header definitons in simgear/compiler.h that would make these lines: #include STL_IOSTREAM Here! Here! Technically only istream is needed but since a lot of older compilers don't have it I can live with Erik's solution. Another solution would be to provide our own istream that pulls in a suitable header. Same goes for other missing Std C++ headers. It might help to reduce preprocessor noise. Erik, I was thinking we could use Boost's compatability library I sent you as a starting point. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Linux IDE
Christian Mayer wrote: Hi, beware of possible flame war as I'm now ready to run Linux frequently, I'm looking for a comfortable IDE for the development. Has anyone exprience? Does KDevelop work nicely together with FGFS? Do I need to make spacial adjustmenst (on anyside)? Oh, BTW, EMACS and VI/VIM are no option for me (vim is greqat to change a file, but not to have a overview over a big project) CU, Christian There is an IDE project called anjuta at sourceforge. The interface is very Visual Studio-ish. It is based on GTK/Gnome rather than KDE. I've only had a quick look at it but it seems fairly easy to use at its current stage of development. Bernie (dedicated emacs users) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Attaching to the network interface
Scott G. Miller wrote: I'm considering writing a scripting language interface to FlightGear to experiment with script driven weather and aircraft failure events. Is there a pointer to any documentation on interfacing with running flightgear on its http server? I'm implementing a similar idea except using the telnet interface (--props=...) instead of http. None of this stuff is in cvs yet. In answer to your question though, http requests are handled by the HttpdChannel::foundTerminator() function in Network/httpd.cxx. Ah of course. I do have one question to whoever is implementing the telnet interface, though. I can use it fine exactly once. A second connection is accepted by fgfs, but does not respond to any commands. This makes debugging my code very difficult, as I have to restart flightgear each time. There was a bug in the network code that prevented subsequent connections from getting through but I believe it is fixed in cvs. The current props/telnet server doesn't support multiple simultaneous connections. I have a fix in the pipeline but Curt has been busy. FWIW I have written a python class that interfaces to the props server. It provides a dictionary-like interface to the property system. For example: import FlightGear # Establish a connection to the FlightGear props server fg = FlightGear.FlightGear( localhost, 5500 ) # Apply the parking brake fg[/controls/parking-brake] = 1 # Display the current heading print fg[/orientation/heading-deg] # Display all toplevel properties for prop in fg.ls(): print prop Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Update Missing in config.h-msvc6
Curtis L. Olson wrote: Ugh, that's ugly. The configure script takes care of this automatically with unix/cygwin. Could something be done with the am2dsp.pl script? Tricky! The am2dsp.pl script doesn't touch config.h.in. However I could get the AM_INIT_AUTOMAKE version string from configure.in (0.7.10pre1 or whatever), concatenate it with MSVC6-WIN32- and then pass it on the compiler command line, -DFLIGHTGEAR_VERSION=... Let me investigate further before I decide on a solution. Bernie Jonathan Polley writes: The 0.7.10 version of config.h-msvc6 reports itself as #define FLIGHTGEAR_VERSION MSVC6-WIN32-0.7.9 Which gets printed on startup. It also exports the following version constant. #define VERSION 0.57 Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
