Re: [Flightgear-devel] Compiler error with Cygwin SimGear 0.0.16
Curtis L. Olson wrote: BERNDT, JON S. (JON) (JSC-EX) (LM) writes: What is MetaKit, anyhow? Metakit is a lightweight, simple, embedable database library. We use it to store key/value pairs on disk (airport id vs. the airport info for instance.) It can take several seconds (more on some slower disk subsystems) to load all the airport in memory at startup, and it just makes a lot more sense to leave it on disk and fetch the pieces we need when we need them. Should also mention that it runs on the Mac and that it has python and tcl interfaces. BTW The version of MetaKit we distribute is fairly old now. 2.4.2 is the latest. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear Class definition
Erik Hofman wrote: Hi, Today i have taken some time to take a look at the SimGear code and decided it might be time to create a new class definition. I'm not sure this is the right time to discuss about it. But then again, I always have the feeling it might not be the right time. ;-) This is a definition which i feel refelcts the layout of Simgear the best. It is not something which should be implemented before next week or even the next release. I have the feeling that it is something for after the 0.8.0 release of FlightGear. If anybody has any suggestions or comments please let me know, so i could ask Curtis to publish the best release somewhere on the website (just as a confrontation) ;-) If things have settled down (and implementing has begun) I was planning API documentation in html/what_ever form, which could make life easier for new developers. Erik Refactoring SimGear is probably a Good Thing since it has accumulated some cruft over time and some areas need reworking. However I don't think that having bogus top level classes is a good idea. Instead I propose we use namespaces. Perhaps a top level SimGear namespace with second level namespaces corresponding to the major functional divisions, as you've outlined. I think we should eliminate the Misc group as well. I've been using the Boost libraries (http://www.boost.org) for some time now and that is what they do. Portability is one of Boost's goals. I also wouldn't mind the opportunity to refactor the compiler configuration stuff similar to how Boost has done it. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear Class definition
David Megginson wrote: Bernie Bright writes: Refactoring SimGear is probably a Good Thing since it has accumulated some cruft over time and some areas need reworking. However I don't think that having bogus top level classes is a good idea. Instead I propose we use namespaces. Perhaps a top level SimGear namespace with second level namespaces corresponding to the major functional divisions, as you've outlined. I think we should eliminate the Misc group as well. I've been using the Boost libraries (http://www.boost.org) for some time now and that is what they do. Portability is one of Boost's goals. I also wouldn't mind the opportunity to refactor the compiler configuration stuff similar to how Boost has done it. I agree strongly on namespaces -- they'll eliminate some of our MSVC conflicts as well, especially if people avoid using global #defines whenever possible. Do all of our target compilers now support them? I believe so, although some just ignore namespace declarations (gcc-2.95!). My only guideline is Boost, it targets many the same platforms we do (and some we don't). Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Runway markers
Alex Perry wrote: [snip] I don't recall whether the taxiways are named in the taxiway file ? If not, is there even a field were we can optionally add the names ? I believe the taxiways are are all named - in the original default.apt.gz. However there is room for a three or four character name field. Because, generating the yellow/black signs is relatively easy if the taxiway database has the names in, and adding the names to an existing database of taxiways is a lot quicker than drawing them in the first place. I've been working on an airport design tool somewhat like X-Plane's WorldMaker. Adding taxiway names shouldn't be too difficult to add. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Including instrumenst was: Re: [Flightgear-devel] c310 Panel
Norman Vine wrote: John Check writes: Eventually, I guess you could have a separate subdirectory for each instrument, with a README, etc. Think of yourself as a fine craftsman, like a watchmaker. err.. uhh... umm.. whatever. I'd like to stay away from excessive directories. Maybe if the instruments were stored as tarballs I think we are getting close to where we want a more flexible file system. We are already doing something along these lines with the Scenery. ie. when we look for a tile it can either have a .gz extension or not and we use the gzf__() functions on the compressed files and norman stdio f_() functions if it doesn't. This concept could fairly easily be extended to include directories. The zlib functions handle uncompressed files so there shouldn't be any need for FILE* functions. BTW sg_gzifstream.open(const char* fname) attempts to open fname with and without the .gz extension. Kind of like Jar files in Java :-) We could even walk both the compressed and the uncompressed tree and use the 'newest' file for easy experimentation. Easy and slow. I remember someone once saying on this very list that file opening is a performance killer :) Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Makefile.am / autoconf problems
Curtis L. Olson wrote: Bernie, I don't believe make allows 'circular' dependencies like that. I know at least some versions do not. Would be awfully convenient, but I don't think it is allowed. Curt. On the other hand FOO += bar is an extension not available to all makes. We seem to be stuck between a rock and a hard place! Bernie, now on his second cup of coffee. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Change in Canonical Build Proceedure ???
Norman Vine wrote: It appears as if recent changes in the CVS requires a modification in the steps for building FGFS 1) for now, with Cygwin at least, you NEED to add AC_PREREQ(2.13) as the first REAL LINE in configure.in I am investigating this as it shouldn't be necessary 2) Everyone NEEDS to run autoheader as src/include/config.h.in is no longer in the CVS files Therefore the canonical sequence for building FGFS from a fresh CVS checkout is now % rm config.cache % aclocal % autoheader % automake -a % autoconf % ./configure --YOUR_CONFIGURE_OPTIONS % make I think its time to add an autogen.sh script to bootstrap the build process. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Hello? Is anyone listening?
Christian Mayer wrote: Alex Perry wrote: (Here, I try to estimate the download size when doing my first ever csv update, on slow time-metered isdn. CVS (it'll take you a few weeks to get the hang of typing it right 8-) is a very efficient method of doing the transfer, but it is not compressed. Isn't there a option (I think it's -Znumber with number = 1...9) to compress normal CVS? -z3 (note case) gives the best compression/performance ratio. Higher numbers may produce slightly better compression but require more grunt on the server. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Compile error latest CVS
John Check wrote: Latest CVS build dies with following error make[4]: Entering directory `/home/j4strngs/Repository/FlightGear/src/FDM/JSBSim' c++ -DFGFS -I../../.. -I../../../src -I/usr/local/include -I/usr/X11R6/include -g -O2 -c FGTable.cpp FGTable.cpp: In method `void FGTable::Print()': FGTable.cpp:228: `ios_base' undeclared (first use this function) FGTable.cpp:228: (Each undeclared identifier is reported only once FGTable.cpp:228: for each function it appears in.) FGTable.cpp:228: parse error before `::' make[4]: *** [FGTable.o] Error 1 g++ 2.95.x lacks the Standard's ios_base class. One messy work around is demonstrated in simgear/misc/zfstream.hxx. FWIW I've been working on an alternative solution using namespaces that is much cleaner. It compiles with gcc 2.95.x and 3.0.x, Intel C++ and MSVC6. Another alternative is that the offending code can be rewritten slightly more portably using cout.flags() and/or cout.unsetf() though I haven't fully investigated this. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Observations on latest cvs flightgear
David Megginson wrote: Cameron Moore writes: The output from SG_INFO to the console (Event states, mouse in view/pointer mode, lighting updates and tile updates) can cause nasty pauses on Windows 98 even with the console window minimised, far worse than on NT on the same hardware. May I suggest that we turn off all the console output during flight by default and let users turn it on if they wish. I've got a Feature Request item[1] for this on SF. I seriously doubt I'll have free time to hack on this before the feature freeze, so if it's going to get into 0.7.9, someone else is going to have to do it. One of the problems is that JSBSim does its own output outside of the SG_LOG infrastructure. We'll need to modify JSBSim to allow custom logging interfaces, and that might be a bit of a tedious chore. You can disable cout by setting its failbit. Alternatively you could replace cout's streambuf with one that discards its output. This won't work for SG_LOG() since it doesn't use cout. However I have a new namespace'd version that does use cout. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help offered !!!
David Megginson wrote: [snip] We're also very interested in contributions from C++ coders -- there are areas in FlightGear that still need an awful lot of work, and perhaps more importantly, there are thousands of lines of existing code that need to be reorganized to simplify the architecture and make it more consistent. If you're interested in 3D work or GIS, you might want to look at our scenery-generation software TerraGear, which has been sadly neglected of late. Perhaps we need a TODO file in cvs containing specific suggestions and/or small project ideas. Something like the projects page on the website but with more detail. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ancient 'ascii' scenery format
Wolfram Kuss wrote: Curt asked: Is anyone still using this ancient file format? Yes. Does anyone have any objections to ending support in flightgear for it? Is it easy to create a atg2btg converter (I only have btg2atg) or does someone write a btg importer/exporter to plib? If so, then it is completely ok by me. I've been working on a btg importer for plib/ppe. Once I've got something useable I'll announce it on the appropriate mailing lists. atg2btg should be trivial to code. I might even have one sitting around some place. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ Template Question
David Megginson wrote:
I have a question for the C++ heads. Let's assume that I have
something like this:
template class C, class T
T
BindingC,T::get_value () const
{
return (_obj.*_getter)();
}
assuming
C _obj;
T (C::*_getter)() const;
This always gets instantiated correctly when I included it inline in
the header file, but not when I move the definition out to the cxx
file. Is that an inherent limitation of templates? I cannot
pre-instantiate all the templates I might need in the cxx file,
because I don't know what classes people will use this with.
I'll appreciate any help.
I believe this is a limitation with templates. Until all compilers
support the 'export' keyword, template function definitions must be
defined in a header file.
Cheers,
Bernie
Obligatory reference: Perhaps Boost.Function from www.boost.org is
worth looking at?
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Cockpit panel_io.cxx,1.36,1.37
Cameron Moore wrote:
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.03.21 08:58]:
Index: panel_io.cxx
===
RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Cockpit/panel_io.cxx,v
retrieving revision 1.36
retrieving revision 1.37
diff -C2 -r1.36 -r1.37
*** panel_io.cxx 19 Mar 2002 16:12:15 - 1.36
--- panel_io.cxx 20 Mar 2002 14:57:31 - 1.37
***
*** 296,300
}
! if (propName != ) {
target = fgGetNode(propName.c_str(), true);
}
--- 296,300
}
! if (propName != (string)) {
target = fgGetNode(propName.c_str(), true);
}
As Bernie has mentioned before[1], this should be:
if (!propName.empty()) {
And for someone who has time, there's plenty more of these to be fixed:
$ cd FlightGear/src/
$ find . -type f -name '*.[ch]??' | xargs grep -n '[=!]= '
./ATC/ATCmgr.cxx:112: if(last_comm1_ident != ) {
[snip]
Just to make life more complicated, the latest changes to the property
system return const char* instead of std::string. Don't know if it will
have any impact on this todo item.
Bernie
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] inlining
Andy Ross wrote: FWIW, my interest in un-inlining stuff has nothing to do with runtime performance at all. What I want to see is for FlightGear to compile in something under 20 minutes on my machine. Some parts are really just terribly slow to build. JSBSim and UIUC are big culprits here, Personally I only ever fly the default fdm so compiling the others is a waste of my time and resources. Maybe we should add an argument to configure to select which FDM(s) to compile: --with-fdm=all the default, compiles all fdm modules --with-fdm=yasim compiles only the specified fdm Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
Jonathan Polley wrote: With the irregularity that I am having problems with using XXX I get the feeling that there is something wrong with a header someplace, or a #define. Not all modules generate the error, and others (namely the updates, and only the updates, to JSBSim) blow body parts across the room. I can change the behavior of JSBSim by rearranging the #includes in some of the modules, but I cannot get rid of the errors. Is anyone else building under MSVC 6.0 (or other MSVC compiler)? Moving using std::sort after #include algorithm fixes the problem in props.cxx. I build under MSVC6 occasionally though generally I use linux. However I was responsible for resolving some of the early portability issues. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Conditional fgEVENTs
[EMAIL PROTECTED] wrote: Is anyone working with the fgEVENT in Time/event.hxx and related classes? Since our project is a particular simulated space mission, I've been looking at how to cause certain events (text displays and sounds, mainly) based on conditions in the property tree. I didn't find anything to do exactly that, but with fgEVENT and FGConditional, it should be pretty simple to implement. Here's a diagram, with the new parts shaded and blue: http://genesis.cs.utc.edu/~mpaschal/work/gems/conditionalEvents06.png Is this reasonable? Since these conditional events are necessary for how we're working our mission, I intend to write this for our use even if it's not useful generally. One implementation worry is that passing a parameter as part of an fgCallback appears only partially implemented. This feature would be greatly useful so that we could call a 'play sound' function with a particular sound as a parameter rather than having separate 'play sound x' and 'play sound y' functions--but I would have to whip out the C++ books for a while to be able to fix it myself without breaking the existing events, assuming it's possible at all. Your advice is greatly appreciated. An fgEVENT is a function that is executed every X milliseconds. Once per frame the event queue is scanned and any events whose interval has passed is executed. FWIW the current implementation is fairly old and crufty. I have a newer version that replaces fgCallback with boost::function. Boost::bind can also be used which allows arbitrary parameters to be passed to the function when it is executed. FGConditional, I believe, is part of the property sub-system but until now no one has suggested combining them with the event sub-system. Cheers, Bernie PS see http://www.boost.org for more details on boost::function and boost::bind ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0
Jonathan Polley wrote:
On Thursday, March 21, 2002, at 03:37 AM, Erik Hofman wrote:
Jonathan Polley wrote:
After getting SimGear to build under MSVC 6.0 (thanks Christian), I moved
on to getting all of FlightGear to build. For some reason, MSVC does not like JSBSim
(over 1200 errors generated) but I had no problem under RH 7.1 (as usual). I expect
that everything is a snow ball started from the errors in FGPropertyManager.h.
The full build result file can be found at:
http://homepage.mac.com/eq_fidget/FG_Dox/FlightGear.html
It's just a matter of removing (*all*) the 'FGPropertyManager::' sections
within the class (or file).
Erik
When I do that, it complains about the multiple definitions of 'Tie.' When it starts
failing the compile, it is on the second, and subsequent, definitions of
'FGPropertyManager::Tie.'
When I comment out *ALL* instances of 'Tie' (however you want to define it), I still
get a major explosion which makes absolutely NO sense:
[snip]
You're right, it doesn't make any sense. Perhaps you commented out too
much?
Anyways, I've managed to compile a recent FlightGear JSBSim. The
problems I encountered seem to be that MSVC can not deduce which
overloaded member function to call:
Compiling...
FGAerodynamics.cpp
c:\src\flightgear\src\fdm\jsbsim\fgaerodynamics.cpp(229) : error C2661:
'Tie' : no overloaded function takes 4 parameters
Adding an ugly cast fixes the problem:
PropertyManager-Tie(forces/fbx-aero-lbs, this,1,
(double (FGAerodynamics::*)(int) const) FGAerodynamics::GetForces);
A similar cast is required on every pointer to member function that
takes an index, probably because there is a similar named member
function that takes no index:
class FGAerodynamics : public FGModel {
...
FGColumnVector3 GetForces(void) {return vForces;}
inline double GetForces(int n) const {return vForces(n);}
On that note, since we are taking a pointer to a member function, the
compiler must emit a function body. Thus the member function can't be
inline. This may help decide which functions to inline.
Cheers,
Bernie
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0
Jon Berndt wrote:
Adding an ugly cast fixes the problem:
PropertyManager-Tie(forces/fbx-aero-lbs, this,1,
(double (FGAerodynamics::*)(int) const) FGAerodynamics::GetForces);
I'll roll that change into my copy until it gets made permanently. While
We'll do a little investigating, first. I want to understand why MSVC is
having problems, first, when no other compiler appears to be complaining. We
want to remain as cross-platform/cross-compiler compatible as possible, but
as a matter of policy, I am extremely hesitant to make crutches in our code
to fix a crippled compiler - if, indeed, it turns out to be a problem with
MSVC. Do you have any explanatory backup for why MSVC isn't working with
this? I know this sounds rude of me, but I hope you can see where I am
coming from.
I'm not sure if it is actually a problem with MSVC or if other compilers
have different rules when it comes to taking the address of an
overloaded function. I have encountered this exact same problem before,
with even gcc requiring a cast to disambiguate pointers to overloaded
member functions. Note that the cast is portable, I've tested with gcc
2.95.3 at least.
The only explanation I can offer is that FGAerodynamics::GetForces is
ambiguous given the declaration
class FGAerodynamics : public FGModel {
FGColumnVector3 GetForces(void);
double GetForces(int n) const;
...
The cast is a hint to the compiler which of the two GetForces() member
functions we are taking the address of. I have no idea why MSVC can't
deduce the correct member while other compilers can but that is the
essence of the problem as I understand it.
Cheers,
Bernie
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0
Norman Vine wrote: Jon, I don't think there is a 'conforming' compiler yet, and MSVC6 is several years old and I wonder how well the then current gnu stdlib++ would have handled that construct :-)) I believe Comeau is 99.9% conforming but it is not free. I also believe that MSVC7 is much much better, they are using boost (http://www.boost.org) as one of their conformance acceptance tests, as are the gcc 3 crew. That said I will agree that MSVC6 even with all the service packs is a 'little' behind most of the others in being able to handle some of the more 'arcane' bits of C++. There is STLPort however that should work just with just about any compiler even MSVC :-) True, however this particular problem is compiler related not library related for once. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MicroSoft Visual C++ Deficiencies
Jonathan Polley wrote: On Sunday, March 24, 2002, at 11:32 PM, Norman Vine wrote: FYI http://hammer.prohosting.com/~yotam/software/msviscxx/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel I think that will be added to chapter 150 of my book on Why I Love Using Microsoft Products. My guess is that we have something related to the Function Template Parameter problem. Although the errors I got correspond to Confused by Template Forward Declaration. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0
Tony Peden wrote: It's unfortunate but I think we're going to have to incorporate this cast. However, I do think we could clean it up a bit with a pre-processor define: #define AEROINTFUNC double (FGAerodynamics::*)(int) const then PropertyManager-Tie(forces/fbx-aero-lbs, this,1, (AEROINTFUNC)FGAerodynamics::GetForces); Hopefully, its still clear that that is a cast. Assuming Jon does not object, I will accept patches that look like the above. Okay, I'll make the changes to the current JSBSim cvs snapshot (not the one in FlightGear) and send you the patches. However I might try a typedef instead of a macro. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC6 - Current cvs - 25 March
Geoff McLane wrote:
Hi,
I can see nothing 'wrong' in the construct in
FGPropertyManager.h that should give 'pause'
to a compiler ... as other compilers have proved.
The construct is legal Std C++. MSVC is at fault.
You will note msvc does NOT require any such
'agressively additional casting' when used in the
5 parameters case -
That is, from say FGAircraft.cpp -
This FAILS
PropertyManager-Tie(metrics/eyepoint-z-ft, this,3,
FGAircraft::GetXYZep);
While this WORKS Why ???
PropertyManager-Tie(metrics/alpha-max-deg, this,
FGAircraft::GetAlphaCLMax,
FGAircraft::SetAlphaCLMax,
true);
The difference is in the 'casting' of the (*getter).
In the second the getter is 'double get()' style, while
the 'other' getter is 'double get(index)' style, and the
compiler misses the connection ...
The difference is that there are two FGAircraft::GetXYZep functions:
class FGAircraft {
inline FGColumnVector3 GetXYZep(void) { return vXYZep; }
inline double GetXYZep(int idx) const { return vXYZep(idx); }
MSVC is unable to disambiguate them given that the
FGPropertyManager::Tie prototype is visible and that V
(T::*getter)(int) const is an exact match when T=FGAircraft and
V=double. Removing the inlines doesn't help either. The conclusion is
that MSVC is wrong but we can help it by providing a hint in the form
of an appropriate cast.
Your second example works because there is only one
FGAircraft::GetAlphaCLMax(). As a test I added an overloaded
GetAlphaCLMax(int) const member function and got the same compilation
error.
Cheers,
Bernie
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC6 - Current cvs - 25 March
Geoff McLane wrote: Also, such function additions gives the compiler/linker a chance to really make this 'inline', since the double value could be 'addressed' in simple lines, when loaded, like moveax, [0x12345678]; get that double movedx,[0x12345678+4] or in 64-bits lodreg1, [0x1234567812345678]; load double which is all we can ask for 'inline' ... Except that by taking the address of the function we force the compiler to emit a function body despite the inline qualifier. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] I can't compile flightgear0.7.9 in Microsoft Visual C++ 6.0
way lee wrote: I meet a problem when I compile flightgear0.7.9. The VC compiler told me that there was no mk4vc60s.lib. I can't find it in CD-image. Can you tell me where is it? mk4vc60s.lib is the Metakit library. The source is included as a separate tar.gz file in the SimGear tar file. You will need to un-tar and compile it yourself. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC6 Build Progress
David Megginson wrote: Jonathan Polley writes: I reverted input.hxx back to what was in CVS and moved the enumeration from being private to public and MSVC now likes using an enumeration element to define an array. Why the compiler cares about an enum being private vs. public, I will never know (although I have seen this behavior before). I also brought in the newest input.cxx and I can now run FlightGear again. Does it still work if the enum is protected? I'd like to keep things as well encapsulated as possible. You can keep the enum private if you add the following declarations immediately afterwards: struct mouse; friend struct mouse; It seems that MSVC doesn't grant the nested mouse decl. any special access privileges to its surrounding class. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear w/OpenGC question
Damion Shelton wrote: Hi all, Some time back John started using Simgear in OpenGC to form the basis for our local nav database. Although this works fine under Cygwin and Linux, until recently I had problems with it under Windows. The problem turned out to be the following: The two libraries that OpenGC links with, besides Simgear, are FTGL and Freetype 2.06. Under Windows, both of these are set to build with the /MD (multithreaded DLL) compiler option. Simgear is set to build with the /ML (single-threaded) libraries. Linking with both of these simultaneously was causing more than a few linker errors (OpenGC was set up to link using /MD as well). Without Simgear, everything worked fine. By rebuilding FTGL and OpenGC with the /ML library flag, everything seems happy. Although there are no immediate plans to support multithreading in OpenGC, it would be more convenient to Windows users if they did not have to modify the build process in order to allow compatibility with Simgear. Any Windows/Simgear gurus out there have any suggestions? Its trivial to recompile SimGear multithreaded (/MT). I can make this the default since it is the also the default for plib and metakit. Note that SimGear cannot be compiled as a DLL. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: Boost - http://www.boost.org/
Christian Mayer wrote: Curtis L. Olson wrote: Bernie Bright has submitted a simplified boost distribution for SimGear and I have committed it to CVS. The boost web page is here: http://www.boost.org/ We will begin depending on this package soon. Well, *I* don't really understand what boost is usefull for. Can somebody tell me what boost does and why it's important for us, please? Boost was begun by members of the C++ Standards Committee Library Working Group, although membership has expanded to include nearly two thousand members of the C++ community at large. Its aim is to develop existing practice and provide reference implementations of possible future additions to the C++ Standard Library. Several Boost libraries have already been presented to the library working group and have met with a favorable response (that is, it is quite likely that they will become part of the next C++ standard library). I have asked Curt to include a subset of Boost that includes just Boost.Function and Boost.Bind (plus required support and configuration files). These are all header files so there is nothing to compile. Boost.Function is a family of class templates that implement function objects. It generalises the idea of callback functions such that free functions and member functions are treated identically. This means that anywhere we store a function pointer or an object pointer plus pointer-to-member-function we can store a single boost::function object instead. Boost.Bind is a generalisation of std::bind1st(), std::bind2nd() and std::mem_fun(). It is used in conjunction with Boost.Function to bind an object and a pointer to a member function into a single function object. It is a smarter and more elegant replacement for our fg_callback. Boost has a lot to offer if you are doing any serious C++ development. For example smart pointers, a regex library, compile time assertions and threads have all been presented to the committee. Remember, what is in Boost today may appear in the C++ standard tomorrow :) Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with templates
Marcio Shimoda wrote: Unfortunately this doesn't seem to be the complete error message, so I cannot se what's happening. You might want to post the complere error message, together with the OS and compiler you are using. Erik Well, this is a long warning/error message... I'm using MSVC6 and Win98. Compiling... fg_fx.cxx c:\arquivos de programas\microsoft visual studio\vc98\include\map(27) : warning C4786: '??R_Kfn@?$map@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@ @PAUsample_ref@@U?$less@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@ D@2@@std@@ @2@V?$allocator@PAUsample_ref@@@2@@std@@QBEABV?$basic_string@DU?$char_traits @D@std@@V?$allocator@D@2@@2@ABU?$pair@$$CBV?$basic_string@DU?$char_traits@D@ std@@V?$allocator@D@2@@std@@PAUsample_ref@@@2@@Z' : identifier was truncated to '255' characters in the browser information Try adding #include simgear/compiler.h as the first include statement of fg_fx.cxx. Warning C4786 is harmless, identifier too long, but it obscures any real warnings and errors. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioningquestions
Jon S Berndt wrote:
On Fri, 5 Apr 2002 13:00:00 -0500
David Megginson [EMAIL PROTECTED] wrote:
Jon S Berndt writes:
That's actually becoming a bit of a problem -- I couldn't use FGModel
for the 3D model either because JSBSim had already taken it. As Andy
keeps reminding us, it would be a good idea to put JSBSim and possibly
SimGear into their own namespaces to avoid conflicts like these.
Yeah, I've considered that for some time, just haven't
gotten around to it. But, I guess if it's causing so many
problems, maybe we need to just go ahead and do it.
Another reason I have waited is because even though I know
how to use stuff in other namespaces, I'm not positive
that I know how to go about putting our stuff into a
namespace. Can anyone explain this to me?
Its pretty simple. Just wrap the contents of all your header and source
file with:
namespace JSBSim {
...
}
Users of the your classes would refer to them as JSBsim::Foo. I would
advise against a using namespace JSBSim; directive since that
re-introduces the problem we are attempting to solve. Even a using
JSBSim::Foo; declaration is risky if Foo is declared elsewhere.
I have experimented with namespaces in SimGear with good effect. For
instance, SGEphemeris wraps quite nicely into its own namespace:
namespace simgear {
namespace ephemeris {
class SGEphemeris {...};
class CelestialBody {...};
class Venus : public CelestialBody {...};
}
}
Only a couple of minor changes to FlightGear were necessary, references
to SGEphemeris become simgear::ephemeris::SGEphemeris.
With namespaces we could even drop the SG prefix.
Cheers,
Bernie
PS I think YASim is in its own namespace so you could look there for
inspiration.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boost?
John Wojnaroski wrote: Okay, I need a boost ;-0 Downloaded the files. Tried the header files in several locations, but ./configure would not (could not) find them Is it /usr/include or ~/SimGear/ or ~/SimGear/simgear/ or /usr/local/include/ or..? You can install them where ever you like as long, then add the include path to CXXFLAGS before calling configure: CXXFLAGS=-Ipath-to-boost ./configure If you are using gcc then /usr/local/include is an obvious location since gcc looks there anyway. In this case you don't need the CXXFLAGS trick. Do you need more than the headers? like libraries, or are the headers self-contained as noted in the install manual? The subset of boost I've supplied is headers only. There is nothing else to compile or install. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC Still not Building
To avoid this problem in future, maybe we should define a macro in
simgear/compiler.h. Something like:
#ifdef SG_NO_INCLASS_MEMBER_INITIALIZATION
# define SG_STATIC_CONSTANT(type, assignment) enum { assignment }
#else
# define SG_STATIC_CONSTANT(type, assignment) static const type
assignment
#endif
Usage then becomes:
class Foo {
SG_STATIC_CONSTANT(int, FG_MAX_ENGINES = 4);
...
}
which expands to either
static const int FG_MAX_ENGINES = 4;
or
enum { FG_MAX_ENGINES = 4; };
I think the problem with Norman's solution is that you can't use the
value later in the class declaration, as an array size for example.
Cheers,
Bernie
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FYI: Re BOOST
Jon S Berndt wrote: This month's issue (MAY 2002) of C/C++ User's Journal contains the article: The Boost.Threads Library. The issue focuses on multithreading. Matt Austern and Herb Sutter regularly mention Boost in their articles and at the C++ experts forum at http://www.cuj.com/experts/. Both have contributed code and/or criticisms. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Ambient lighting
Curtis L. Olson wrote: David Megginson writes: All ambient lighting has suddenly vanished from my FlightGear, even with my previously-built binary. I still see the 2D panel and the runway lights, but nothing else, no matter what the time of day. Other 3D programs like Blender and TuxRacer are still working fine. Has anything else ever noticed a problem like this? Yes, I'm seeing that too. Bernie, I wonder if it has something to do with the recent event manager changes? The scene recovers after the first time update (30 seconds into the sim run.) I think before, the event manger must have run the routine at schedule time and then at the requested interval after that. Your analysis is correct. The old event manager executes an event when it is registered and then subsequently every 'interval' milliseconds. I can replace the old behaviour but wonder if I should. IMO registering an event to be run every x millseconds doesn't imply running it immediately. Thoughts? BTW David, Boost is no longer used. Some older compilers were having trouble with Boost's advanced template usage. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Ambient lighting
Curtis L. Olson wrote: Bernie Bright writes: Your analysis is correct. The old event manager executes an event when it is registered and then subsequently every 'interval' milliseconds. I can replace the old behaviour but wonder if I should. IMO registering an event to be run every x millseconds doesn't imply running it immediately. Thoughts? It seems reasonable to me to run the task once when it is registered and then subsequently at the requested interval. Okay. Here's a patched FGEventMgr.cxx that executes the callback upon registration. Cheers, Bernie FGEventMgr.cxx Description: application/unknown-content-type-cxxfile
Re: [Flightgear-devel] Ambient lighting
Alex Perry wrote: Personally, I've always preferred that event registration takes two parameters; the first delay time and the repeat delay time. This lets you do one-shot as well as immediate and non-immediate modes. Can we do something like that with Boost in future ? Obviously we can support it right now if we want to. I like that idea. Something like setitimer() and the itimerval struct under Unix. I'll investigate adding an initial delay time in addition to the repeat interval. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Update Missing in config.h-msvc6
Curtis L. Olson wrote: Ugh, that's ugly. The configure script takes care of this automatically with unix/cygwin. Could something be done with the am2dsp.pl script? Tricky! The am2dsp.pl script doesn't touch config.h.in. However I could get the AM_INIT_AUTOMAKE version string from configure.in (0.7.10pre1 or whatever), concatenate it with MSVC6-WIN32- and then pass it on the compiler command line, -DFLIGHTGEAR_VERSION=... Let me investigate further before I decide on a solution. Bernie Jonathan Polley writes: The 0.7.10 version of config.h-msvc6 reports itself as #define FLIGHTGEAR_VERSION MSVC6-WIN32-0.7.9 Which gets printed on startup. It also exports the following version constant. #define VERSION 0.57 Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Update Missing in config.h-msvc6
Bernie Bright wrote: Curtis L. Olson wrote: Ugh, that's ugly. The configure script takes care of this automatically with unix/cygwin. Could something be done with the am2dsp.pl script? Tricky! The am2dsp.pl script doesn't touch config.h.in. However I could get the AM_INIT_AUTOMAKE version string from configure.in (0.7.10pre1 or whatever), concatenate it with MSVC6-WIN32- and then pass it on the compiler command line, -DFLIGHTGEAR_VERSION=... Let me investigate further before I decide on a solution. Further investigation reveals that FLIGHTGEAR_VERSION is defined in src/Include/version.h. If we just want the version without the MSVC6-WIN32- prefix then we can just delete the relevant line from config.h-msvc6. Otherwise I can trivially modify am2dsp as above. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
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] 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] 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] 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
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] 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
[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] 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
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] 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
[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] 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
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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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
[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] 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
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] 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] 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] 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] 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
[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] 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
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] 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] 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] 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
[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] 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
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] 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] 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] 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: 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] 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
