[Flightgear-devel] CVS simgear/magvar/coremag.cxx error
Could someone with simgear CVS access please fix the coremag.cxx file.Each time I checkout (or update) this file has this in its head :- coremag.cxx// $Id: coremag.cxx,v 1.5 2006-10-28 22:12:48 curt Exp $===// $Id: coremag.cxx,v 1.6 2008/07/25 18:35:42 ehofman Exp $ 1.6 I understand this is a known CVS problem where a checkin was not with the same version as already in CVS ... it has been like this for months - maybe since July 2008! Coincidently, the link on the page http://www.simgear.org/cvs.html to 'Interactively peruse the CVS logs ...' does not work, so can not check further into the CVS history of this file ... Thanks, and regards, Geoff. PS: Sorry if this is a repeat, but the first send seemed to fail??? _ More than messages–check out the rest of the Windows Live™. http://www.microsoft.com/windows/windowslive/-- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft inter-dependencies for sound and OpenAL
Hi Stuart,
Re: OpenAL sound library
(AL_INVALID_VALUE): constructor (alBufferData) Fatal error: Failed to
buffer data.
I think the ONLY reason you would get this not very helpful specific message is
that the FG/SG is compiled against an ALUT previous to version 1, if it still
exists?, or the header alut.h has NOT been included - see CVS
simgear\sound\sample_openal.cxx, around line 147 and above for later code ...
I had this error and problem, when switching to using OpenAL SDK in native
WIN32, which no longer places the al.h in an AL folder, thus I had to modify
the OpenAL includes, and accidentally also left out AL/alut.h, which remains
in an AL folder in the now separate alut source - Simgear library appears to
compile fine without it in this file, but ...
In fact it is maybe better to totally remove this '#else' code completely, and
an #error to abort the compilation. By now several other sub-systems depend in
the sound manager initializing ALUT in the constructor, such that this
'alternate' pre version 1 code no longer works at all, even if you add an
alutInit(), which will get past this particular error, but causes many others
...
Been there, done that ;=))
Attached below is a patch that REMOVES the code trying to support alut earlier
than 1. As can be see it also effects simgear\sound\soundmgr_openal.cxx. The
_FULL_ patch file for my last build, containing this OpenAL patch, is
http://geoffair.net/fg/txt/fgfs-047.patch.txt ...
This patch, extracted from the above full patch, also contains my NEW switch -
USE_OPENAL_SDK - in a few other files as well, to account for the 'new'
location of al.h in the OpenAL SDK, if used.
Hope this helps ...
Regards,
Geoff.
site: http://geoffair.net/fg/ - dedicated to building FG in WIN32
alut_patch
diff -ur CVS\SimGear\source\simgear\sound\sample_openal.cxx
Simgear\simgear\sound\sample_openal.cxx
--- CVS\SimGear\source\simgear\sound\sample_openal.cxx Fri Oct 31 15:14:15
2008
+++ Simgear\simgear\sound\sample_openal.cxxWed Dec 03 13:35:03 2008
@@ -30,7 +30,11 @@
# include OpenAL/al.h
# include OpenAL/alut.h
#else
+#ifdef USE_OPENAL_SDK
+# include al.h
+#else
# include AL/al.h
+#endif
# include AL/alut.h
#endif
@@ -136,19 +140,8 @@
}
#else
-//
- // pre 1.0 alut version
-//
-ALvoid* data = load_file(path, file);
-
-// Copy data to the internal OpenAL buffer
-alBufferData( buffer, format, data, size, freq );
-
-if ( print_openal_error(constructor (alBufferData)) ) {
-throw sg_exception(Failed to buffer data.);
-}
-
-alutUnloadWAV( format, data, size, freq );
+#pragma message(ERROR: ALUT_API_MAJOR_VERSION not defined, or less than 1!
Has alut.h been included?)
+#error Earlier versions of alut no longer supported by FlightGear
#endif
print_openal_error(constructor return);
diff -ur CVS\SimGear\source\simgear\sound\sample_openal.hxx
Simgear\simgear\sound\sample_openal.hxx
--- CVS\SimGear\source\simgear\sound\sample_openal.hxx Fri Oct 31 15:14:15
2008
+++ Simgear\simgear\sound\sample_openal.hxxSun Nov 02 16:06:38 2008
@@ -48,8 +48,12 @@
# include OpenAL/al.h
# include OpenAL/alut.h
#else
+#ifdef USE_OPENAL_SDK
+# include al.h
+#else
# include AL/al.h
# include AL/alut.h
+#endif
#endif
#ifndef HAVE_WINDOWS_H
diff -ur CVS\SimGear\source\simgear\sound\soundmgr_openal.cxx
Simgear\simgear\sound\soundmgr_openal.cxx
--- CVS\SimGear\source\simgear\sound\soundmgr_openal.cxx Wed Sep 10 11:29:08
2008
+++ Simgear\simgear\sound\soundmgr_openal.cxxWed Dec 03 13:53:28 2008
@@ -33,9 +33,14 @@
# include OpenAL/al.h
# include OpenAL/alc.h
#else
+#ifdef USE_OPENAL_SDK
+# include al.h
+# include AL/alut.h
+#else
# include AL/al.h
# include AL/alc.h
#endif
+#endif
#if defined (__APPLE__)
# ifdef __GNUC__
@@ -104,15 +109,8 @@
context = alcGetCurrentContext();
}
#else
-if ( (dev = alcOpenDevice( NULL )) != NULL
- ( context = alcCreateContext( dev, NULL )) != NULL ) {
-working = true;
-alcMakeContextCurrent( context );
-} else {
-working = false;
-context = 0;
- SG_LOG( SG_GENERAL, SG_ALERT, Audio initialization failed! );
-}
+#pragma message(WARNING: ALUT_API_MAJOR_VERSION not set or less that 1! Has
alut.h been included?)
+#error Earlier versions of alut no longer supported by FlightGear
#endif
listener_pos[0] = 0.0;
diff -ur CVS\SimGear\source\simgear\sound\soundmgr_openal.hxx
Simgear\simgear\sound\soundmgr_openal.hxx
--- CVS\SimGear\source\simgear\sound\soundmgr_openal.hxx Fri Oct 31 15:14:15
2008
+++ Simgear\simgear\sound\soundmgr_openal.hxxSun Nov 02 16:06:38 2008
@@ -46,8 +46,13 @@
# include OpenAL/al.h
# include OpenAL/alc.h
#else
+#ifdef USE_OPENAL_SDK
+# include al.h
+# include alc.h
+#else
# include AL/al.h
# include AL/alc.h
+#endif
#endif
#include sample_openal.hxx
/alut_patch
full patch:
Re: [Flightgear-devel] Atlas for FlightGear - new version for Win32.
Hi Igrowing ? cc: [EMAIL PROTECTED] Re: http://atlas.sourceforge.net/ Thanks for the 'reminder' ... As Fred points out the new code is not compatible with Windows (MSVC8) without considerable modification, and some 'hacks' ... Since the last time I did this was way back in 2005, as a challenge, I have done this, and present the results on my FlightGear Build Centre site :- http://geoffair.net/fg/fgfs-044.htm There you can find links to a patch file, a complete set of MSVC8 solution file, and a small set of 'new' files needed to fill in the blanks in the windows 'libc' ... some of these 'kludges' need to be tested ;=// Hope this helps ... Regards, Geoff. EOF - Atlas-01.doc _ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] MSVC8 - Debug assertion in xmlauto.cxx
While running FG under the MSVC8 debugger, I ran across a debug assertion ... index out of range. This patch fixed it - http://geoffair.net/fg/fgfs-042.htm#patch2 But as stated, not sure what this does to the code, but it got me through the debug assertion that the index output[1] was out of range at that time ... maybe someone who knows this particular code could provide a better 'fix' ;=)) Regards, Geoff. EOF - Devel-08.doc _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] MSVC8 - Missing OSG plugin
During my recent build of FG, I missed building the now required osgdb-png.dll, and took some time finding the reason for the 'crash' ... This patch to ModelRegistry.cxx gives more information to the console about the problem, should this, or any other plugin not be available at runtime - http://geoffair.net/fg/fgfs-042.htm#patch Of course the only true 'fix' was to build and install the osgdb-png.dll (and osgdb-zip.dll), but this small defensive piece of coding would have led me to the error quicker ... and seems worthwhile in principal - OSG goes to the trouble of giving a good error message - why not use it? Regards, Geoff. EOF - Devel-09.doc _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Addition of true comms in multiplayer
Friday, October 12, 2007.
Hi Holger,
I have progressed with my WIN32 port of FGCOM, but now a problem with the
910.00 'echo' ...
1. svn checkout svn://svn.dfn.de:/fgcom
This continues to fail - a timeout. Can others checkout this source? I
eventually downloaded and used fgcom-1.0.1.tar.gz ...
2. XMLRPC-C
I had some initial trouble with the xmlrpc-c library. It was NOT formatting a
double correctly in WIN32, but now that has been fixed. I passed these changes,
and lots of others to build in WIN32, to Bryan Henderson
(http://xmlrpc-c.sourceforge.net/techsupp.php), and he has added some changes
to his SVN trunk source. Maybe more to come ...
The simple client/server samples in the XMLRPC-C source all function perfectly
... as does his rpctest suite ...
3. FGCOM 910.00 echo
Server: http://fgcom1.parasitstudio.de:12345/RPC2
I have been trying to do this 'echo' test, to see if my WIN32 aixclient, speex,
etc, is compiled and running correctly, but on 'login' I get back the following
ERROR stuff :-
XML-RPC: InternetReadFileEx( h, buffer=[Sz=40, Next=, Buf=013B3200,
len=889, tot=1301] ... )
XML-RPC: InternetReadFileEx=[TRUE] buffer=[Sz=40, Next=, Buf=013B3200,
len=889, tot=1301]
DATA[?xml version=1.0?
methodResponse
fault
valuestruct
membernamefaultString/namevaluestringerror executing RPC `login'.
Do not know how to thaw data with code `' at /usr/share/perl5/FreezeThaw.pm
line 542
FreezeThaw::thawScalar(0) called at /usr/share/perl5/FreezeThaw.pm line
679
FreezeThaw::thaw('') called at /home/fgregister/fgcom/server/fgreg.pl
line 490
main::_session_check_value('user', 'guest') called at
/home/fgregister/fgcom/server/fgreg.pl line 686
Register::login('guest', 'guest', 'iax', 0, 910) calle...]
XML-RPC: InternetReadFileEx( h, buffer=[Sz=40, Next=, Buf=013B3579,
len=412, tot=1301] ... )
XML-RPC: InternetReadFileEx=[TRUE] buffer=[Sz=40, Next=, Buf=013B3579,
len=412, tot=1301]
DATA[tier/Daemon/ForkingBasicAuth.pm line 70
Frontier::Daemon::ForkingBasicAuth::new('Frontier::Daemon::ForkingBasicAuth',
'methods', 'HASH(0x85bb23c)', 'AuthFile', '/home/fgregister/.fgreg/auth.conf',
'LocalPort', 12345) called at /home/fgregister/fgcom/server/fgreg.pl line 89
/string/value/member
membernamefaultCode/namevaluei44/i4/value/member
/struct/value
/fault
/methodResp]
This is the output from some DEBUG code I added to the xmlrpc-c library, since
I was continually getting 'no connection' ... the DATA[...] is the actual data
received, in two blocks, but a small amount may have been missed.
It seems I am getting a 'connection', but the 'server' bombs executing the
'login' ...
Are others seeing this? It does not seem I can do anything at this client end?
Any help appreciated.
Regards,
Geoff.
EOF - fgcom-03.doc
_
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vistamkt=en-USform=QBRE-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC8 link problem - Missing function in gnnode.cxx?
Tuesday, August 07, 2007. Hi Durk, Vivian, Reagan, et al ... Thanks for the replies ... The reason my MSVC8 complains is simple now that I think about it. I use my OWN flightgear.vcproj file, which includes all modules in a single line, as part of 'main'. Much easier to find sources in a simple alphabetic list ... I also do this for SG. If you are using MSVC, using either the default FG DSP files, or those from the Olaf Flebbe page, then these separate FG into a static library, (or libraries) and a 'main'. You can have unresolved items in a static library without complaint, provided it is never called from 'main' - that is the module is never extracted and added to the EXE by the linker ... Likewise I suspect the gcc build is also separated like this ... I use my own _TWO SOLUTION SYSTEM_ from this page :- http://geoffair.net/fg/fgfs-040.htm Problem solved. Thanks. Regards, Geoff. EOF - Devel-06.doc _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] MSVC8 link problem - Missing function in gnnode.cxx?
Hi Durk,
The file src/Airports/gnnode.hxx declares a function -
FGTaxiNode(double, double, int);
Then in parking.hxx, you added -
: FGTaxiNode(lat,lon,idx);
about July 5 from the CVS logs ...
In WIN32, MSVC8 can NOT locate this function, and marks it as a missing
external.
It seems obvious from the code that this should be something like -
FGTaxiNode::FGTaxiNode(double lat, double lon, int idx)
{
setIndex(idx);
setLatitude(lat);
setLongitude(lon);
}
which I added to gnnode.cxx, and got my clean link, but really wonder why
this has not come up on other systems. How can they resolve
FGTaxiNode(lat,lon,idx);???
Or have I missed something here? The src/Airports/makefile.am seems to
include both parking.cxx and gnnode.cxx since about mid-July ...
Regards,
Geoff.
EOF - Devel-05.doc
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Minor change to avoid (MSVC8) debug assertion
Friday, 06 October 2006.
Minor change to avoid (MSVC8) debug assertion
Oops - While running FG in Debug mode, to check some
other code, I get a debug assertion in groundnetwork.cxx,
which stops me getting to the code I want to
see ;=((
A minor change in the order of the while()
statements fixes this - output with diff -u
--- F:\FGCVS\Flightgear\source\src\Airports\groundnetwork.cxx Thu Sep 21
13:15:54 2006
+++ F:\FG0910-4\Flightgear\src\Airports\groundnetwork.cxx Thu Oct 05
13:50:31 2006
@@ -681,7 +681,7 @@
// Search search if the current id alread has an entry
// This might be faster using a map instead of a vector, but let's start
by taking a safe route
if (activeTraffic.size()) {
-while ((i-getId() != id) i != activeTraffic.end()) {
+while ((i != activeTraffic.end()) (i-getId() != id)) {
i++;
}
}
@@ -704,7 +704,7 @@
// Search search if the current id alread has an entry
// This might be faster using a map instead of a vector, but let's start
by taking a safe route
if (activeTraffic.size()) {
-while ((i-getId() != id) i != activeTraffic.end()) {
+while ((i != activeTraffic.end()) (i-getId() != id)) {
i++;
}
}
@@ -722,7 +722,7 @@
// This might be faster using a map instead of a vector, but let's start
by taking a safe route
TrafficVectorIterator current, closest;
if (activeTraffic.size()) {
-while ((i-getId() != id) i != activeTraffic.end()) {
+while ((i != activeTraffic.end()) (i-getId() != id)) {
i++;
}
}
@@ -760,7 +760,7 @@
TrafficVectorIterator i = activeTraffic.begin();
if (activeTraffic.size())
{
- while ((i-getId() != id) (i != activeTraffic.end()))
+ while ((i != activeTraffic.end()) (i-getId() != id))
{
i++;
}
@@ -876,7 +876,7 @@
TrafficVectorIterator i = activeTraffic.begin();
if (activeTraffic.size())
{
- while ((i-getId() != id) i != activeTraffic.end())
+ while ((i != activeTraffic.end()) (i-getId() != id))
{
i++;
}
@@ -971,7 +971,7 @@
// This might be faster using a map instead of a vector, but let's start
by taking a safe route
if (activeTraffic.size())
{
- while ((i-getId() != id) i != activeTraffic.end()) {
+ while ((i != activeTraffic.end()) (i-getId() != id)) {
i++;
}
}
@@ -989,7 +989,7 @@
// Search search if the current id has an entry
// This might be faster using a map instead of a vector, but let's start
by taking a safe route
if (activeTraffic.size()) {
-while ((i-getId() != id) i != activeTraffic.end()) {
+while ((i != activeTraffic.end()) (i-getId() != id)) {
i++;
}
}
Simply, check if the iterator, i, is not at the end()
FIRST, before doing the i-getId() check ;=)) the assertion
message is something about dereferencing a pointer ... maybe
you should not do i-getId() on the 'end()' member?
I only got the assertion on the first of these changes,
but copied the code to the others, just in case ...
Regards,
Geoff.
EOF - fgd-009.doc
_
FREE pop-up blocking with the new MSN Toolbar - get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] how to see error messages on windows
Hi Fred, http://cvs.flightgear.org/cgi-bin/viewvc/viewvc.cgi/source/simgear/debug/logstream.hxx?annotate=1.9root=SimGear-0.3 Wow, thank you for this pointer ... what a fantastic colour coded 'historic' view you get of the file, ANY file ... I will now REMEMBER this http access ... and then viewing the log showed me that at that moment, your latest patch was 12 hours 41 minutes old ... what precision ;=)) I had already seen them in a CVS update ... And at - http://cvs.flightgear.org/cgi-bin/viewvc/viewvc.cgi/source/src/Main/bootstrap.cxx?view=log I can now read your modification 2 years 6 months ago, to try to 'hide' the console ... hmmm, there was a period about 2.5 years ago where I dropped out of FG for a few months - I moved to Australia for two years, and initially had no computer, nor easy access ;=)) I even turned off the digest ... Anyway, thanks for the quick cvs update ... have updated SG logstream.[c|h]xx, and FG bootstrap.cxx, plus 13 others altered since my last build ;=)), but this does NOT YET solve the 'problem' completely ... In MSVC8, only NOW do I note you have REMOVED the _CONSOLE subsystem define, and put _WINDOWS into the MSVC8 'solution' file ... Yes, I can understand that initially you wanted to NOT open a console window (because it did not look 'professional' ;=/), but after you FOUND that you have to call AllocConsole(), or cerr can freeze, why NOT put FG back to what it is, A CONSOLE APPLICATION?!!!? I had always 'wondered' why using the 'solution' files instead of the DSW/DSP files 'felt' a little different ;=(). BACK TO BASICS! I loaded the DSW/DSP into MSVC8 ... let it do its 'conversion', made the myriad of adjustments to include paths, include libraries, and their respective paths, etc ... and build it all again ... For good measure I chopped out your WinMain in bootstrap.cxx using - #ifndef _CONSOLE #endif // NOT REQUIRED FOR CONSOLE APP but this is not really required ... just as a reminder ... Of course, I ended up building it several times until I got 'everything' RIGHT ... there are so many little things to 'change' ... and some changes cause it to 'start again' ... BAH! Then, am2dsp.pl had not been run for a while so I had to correct the source file list, like removing hud_lat.cxx and hud_lon.cxx ... in fact I got so sick of this, that I ran my own version of am2dsp.pl to generate a 'reasonable' DSP file as a starting point ... A bit like the 'solution' files, it generates a single list of sources all as one FG application ... no separation into 'library' folders ... much easier to find a file in a single alphabetic list ... And I separate source and headers ... this produces a trimmed DSP file ... 75K instead of the original 230K beast ... about the same as the vcproj files ... But my current am2dsp.pl version is pretty messy! At one point I had the idea to use it to modify the vcproj files as well, but eventually abandoned that ... but have not ripped out all the added code ... NOW I HAVE A MSVC8 CONSOLE APPLICATION!, that acts like a console application should ... redirection works fine, and when using fgrun, the messages are to the console, kept open by fgrun ... you have to remember to enlarge the screen buffer, or else you only get a few of the last page ... but it works ... At present, the vcproj 'windows' application will NOT do re-direction, nor use fgrun's console, since WinMain() is called, which sets has_console false ... which causes SG to do the AllocConsole(), etc ... So to Maik, and others ... if you want re-direction, then use the DSW/DSP starting point ... or swap out _WINDOWS define for _CONSOLE before building in MSVC8 ... As stated, thanks for your help on this Fred ... Best regards, Geoff. PS: I have sometimes wondered where the AI planes go, and was 'startled' to find that after chasing one in the UFO - giving the passengers something to talk about - it simply 'disappears' after reaching about 27,000 feet, maybe 10 minutes or so into the flight - now I know they just go into a big bit bucket ;=)) EOF - fgd-005.doc _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] how to see error messages on windows
Hi Maek,
Sorry for the longish post ...
Therefore I added
#ifdef _MSC_VER
cerr Hit a key to continue... endl;
cin.get();
#endif
to function
void fgExitCleanup()
Thank you for bringing this up! ... it has been a problem
for a long, LONG TIME ... IIRC there was a time, in the
far distant past, when re-direction did function ... but
no more ... some change, maybe in PLIB, SG or FG stopped
it completely ...
I really WISH there was a way to re-direct this output
to a disk FILE, so the whole output could be reviewed,
but I have tried, and tried, with simgear logging, but
have never quite succeeded ... I know, it should be
'simple' ;=))
IFF the log output could be directed to a FILE, then
the need for a 'wait key' action at the end would not
really be necessary ... perhaps it could be another
command line action, like --log-to=filename.txt ...
I can see your idea to 'know' whether it is an 'error'
or 'normal' exit, but if it was always written to a FILE,
that file restarted when you next run FG, then you could
check that file in ANY/ALL CASES ... there are ALWAYS
some interesting entries, that SHOULD be explored ...
It is difficult, read IMPOSSIBLE, to enlarge the
windows console buffer big enough so you can 'see' ALL
output ... especially since each iteration outputs a
whole bunch of diagnostic stuff ... many times a
second ... so, even with a 'wait-for-key-exit' you
only 'see' the end ... so this is not really a
complete 'solution' anyway ...
Does anyone have a coded way to 'alter' simgear logging,
such that a FILE could be used in place of cerr ... and
cout for that matter ... IN WINDOWS ... maybe if someone
could code it in *nix, then that code could be 'modified'
for WINDOWS ...
I further 'understand' this re-direction is perhaps
NOT a problem in *nix systems, thus it gets no real
attention ... maybe it is also ok in a cygwin
build and run - have never tried ... thus can NOT
really expect any *nix solution ...
Fred, even when, as you suggest, fgrun is used
as the launcher - since it really aids in setting the
many command line items of FlightGear - a SEPARATE
console window is opened, and closed when FG exits ...
Thus it is NOT output to the fgrun 'console' window,
whether fgrun was started from a console, or as a
shortcut, which create a new console window ... this
is, of course, using a MSVC built fgrun, running in
'pure' windows ...
Are you pointing out that run_win32.cxx has been
'recently' altered to do this? It is certainly
a few weeks or so since I last built fgrun (07SEP06) ...
maybe I just need to do another build ...
But a compare of the run_win32.cxx I used, shows it is the
SAME as the current - perhaps yesterday - svn update
of the fgrun source ... what can you be doing different
to me? My fltk-1.1 was svn updated the same day ... and
PLIB, pthreads, etc, all of that date or more recent ...
And as Reagan points out, although it IS possible to
write a launcher that does re-direction before running
an application, as the MS sample suggests, using threads
and pipes, again this is NOT the NEW console window that FG
NOW creates, but only the console window of the launcher ...
Again, this did work in the now distant past, and I have
such a 'launcher', from approximately the same MS sample
code, which I still sometimes use for other apps, which
I called 'exec32.exe', but it also FAILS with FG ;=(( like
Maik suggested - a broken pipe, or something !!!
Yes, there are some neat functions in FG main(...) like
those used for the macintosh (only) code -
freopen (stdout.txt, w, stdout );
freopen (stderr.txt, w, stderr );
Maybe if this is also done in windows, BUT it will have
to be AFTER -
// set default log levels
sglog().setLogLevels( SG_ALL, SG_ALERT );
since I am very sure sglog() also does something
like this in logstream.hxx ...
inline logbuf::int_type
logbuf::overflow( int c )
{
#ifdef _MSC_VER
static bool has_console = false;
if ( logging_enabled ) {
if ( !has_console ) {
AllocConsole();
freopen(conin$, r, stdin);
freopen(conout$, w, stdout);
freopen(conout$, w, stderr);
has_console = true;
}
return sbuf-sputc(c);
}
else
return EOF == 0 ? 1: 0;
#else
return logging_enabled ? sbuf-sputc(c) : (EOF == 0 ? 1: 0);
#endif
}
In fact I am pretty sure the 'AllocConsole()' call is the
'newish' things that 'breaks' the old re-direction, but have
not had the time to try different things ... or research
back into history ...
As the MSDN help states -
Console applications are initialized with a console, unless
they are created as detached processes (by calling the
CreateProcess function with the DETACHED_PROCESS flag).
It is noted fgrun does NOT add DETACHED_PROCESS ;=() nor
does it add CREATE_NEW_CONSOLE ... it uses 0 for the
'creation flag' ...
So, since a CONSOLE application is started with a
console, initialised by the EXE loader, which may have
Re: [Flightgear-devel] apt.dat and debugging
Wednesday, 23 August 2006. Subject: Re: [Flightgear-devel] apt.dat and debugging I built FG using MSVC 2005, and the release build version works great. I tried to step through the code using the debugger, but ... What I did though was I have created a seperate FG root and use that for debugging (via FG_ROOT environment variable or --fg-root)... I suspected that the solution would be something like this. Your suggestion worked great. Loading the DEBUG version, in the MSVC IDE debugger, or not, will ALWAYS take a LOT LONGER ... in ALL versions of MSVC (7 or 8) ... As you may know, under the DEBUG configuration - (a) EVERY function has additional start and end code, a stack check, that fills the stack with a 'known' value, so on return, it can check if there has been some over-run, or other stack failure ... (b) EVERY allocation of memory using new, uses new_debug (IIRC), and - (i) has the memory filled with a 'known' value, like 0xd...(IIRC) etc, and (ii) keeps a list of the allocations, so the debugger can report use of un-initialised memory, and memory not freed ... And, of course, the DEBUG EXE is usually many times larger than the RELEASE EXE ... and this is increased MORE if you are also using DEBUG versions of the static libraries, like simgear, zlib, plib, etc ... and/or DEBUG versions of the shared libraries (DLL), like alut.dll, openal32.dll, etc ... Things like this cause a VERY SLOW DEBUG configuration load, and running ... separating, and using a trimmed down versions of apt.dat and nav.dat may speed up that part of the load, but, as stated, every function call is SLOWER, and still all memory allocations are so 'guarded' ... But under DEBUG, it does allow you to 'see' the BIG difference between a function call - void foo( string s ) and void foo( string s ) The former must create a copy of the string, involving memory allocation before, and tidy() after, while the latter just passes a pointer to the existing 's' ... I 'hope' linux has 'similar' items to aid in the 'debug' versus the 'release' version ... It is a simple fact of life, that to run FG under the MSVC debugger takes 'forever', ALWAYS ... it does require considerable patience ... but a lot can be learned ;=)) Regards, Geoff. EOF - fg-47.doc _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cygwin CVS compile error
Hi, In a Windows XP machine, running cygwin, latest CVS for simgear and flightgear I am getting the SAME or SIMILAR error when linking FlightGear ... well actually when linking fgjs.exe, under cygwin ... namely - Making all in Input make[2]: Entering directory `/home/GeoffMcLane/FlightGear-0.9-cvs/source/src/Input' g++ -DPKGLIBDIR=\/fg-cvs/share/FlightGear\ -g -O2 -D_REENTRANT -L/fg-cvs/lib -L/usr/local/lib -o fgjs.exe fgjs .o jsinput.o jssuper.o -lplibjs -lwinmm -lplibul -lsgprops -lsgmisc -lsgio -lsgdebug -lsgstructure -lsgxml -lz /fg-cvs/lib/libplibul.a(ulClock.o): In function `_ZNK7ulClock10getRawTimeEv': /home/GeoffMcLane/plib-1.8.4/src/util/ulClock.cxx:79: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status make[2]: *** [fgjs.exe] Error 1 make[2]: Leaving directory `/home/GeoffMcLane/FlightGear-0.9-cvs/source/src/Input' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/GeoffMcLane/FlightGear-0.9-cvs/source/src' make: *** [all-recursive] Error 1 ERROR in make Have read what Georg and Fred wrote ... and having found that libwinmm.a is in /lib/w32api and in /usr/lib/w32api from - $ find / -name *winmm* /lib/w32api/libwinmm.a /usr/lib/w32api/libwinmm.a I altered -lwinmm to -llibwinmm in the 'configure' file, and did ./configure -prefix=xxx, and make again but this time got the error - Making all in Input make[2]: Entering directory `/home/GeoffMcLane/FlightGear-0.9-cvs/source/src/Input' g++ -DPKGLIBDIR=\/fg-cvs/share/FlightGear\ -g -O2 -D_REENTRANT -L/fg-cvs/lib -L/usr/local/lib -o fgjs.exe fgjs .o jsinput.o jssuper.o -lplibjs -llibwinmm -lplibul -lsgprops -lsgmisc -lsgio -lsgdebug -lsgstructure -lsgxml -lz /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -llibwinmm collect2: ld returned 1 exit status make[2]: *** [fgjs.exe] Error 1 make[2]: Leaving directory `/home/GeoffMcLane/FlightGear-0.9-cvs/source/src/Input' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/GeoffMcLane/FlightGear-0.9-cvs/source/src' make: *** [all-recursive] Error 1 ERROR in make I altered the same line in configure.ac from -lwinmm to -llibwinmm and set the environment - $ export LDFLAGS=-L/lib/w32api $ export CPPFLAGS=-DNOMINMAX then did $ ./autogen.sh $ ./configure -prefix=/fg=cvs $ make BUT I STILL GET THE ERROR 'CAN NOT FIND'! on linking fgjs.exe - Making all in Input make[2]: Entering directory `/home/GeoffMcLane/FlightGear-0.9-cvs/source/src/Input' g++ -DPKGLIBDIR=\/fg-cvs/share/FlightGear\ -g -O2 -D_REENTRANT -L/lib/w32api -L/fg-cvs/lib -L/usr/local/lib -o fgjs.exe fgjs.o jsinput.o jssuper.o -lplibjs -llibwinmm -lplibul -lsgprops -lsgmisc -lsgio -lsgdebug -lsgstructu re -lsgxml -lz /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -llibwinmm collect2: ld returned 1 exit status make[2]: *** [fgjs.exe] Error 1 make[2]: Leaving directory `/home/GeoffMcLane/FlightGear-0.9-cvs/source/src/Input' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/GeoffMcLane/FlightGear-0.9-cvs/source/src' make: *** [all-recursive] Error 1 Note, now there is a -L/lib/w32api and -llibwinmm in the g++ command line ... version is ... $ g++ --version g++ (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) The 'configure' and 'configure.ac' of cvs simgear and tar ball of plib-1.8.4, BOTH also use -lwinmm, but I do not get an error compiling plib or simgear ... but would not expect one since these are just static libraries, just for flightgear, well fgjs.exe ... Commenting OUT the following lines in /src/input/makefile.am, I got the rest of FG to compile ... that is killing the fgjs.exe make, and js_demo as well, although it may not be a problem ... I am 'great' at 'hacking' ;=)) #bin_PROGRAMS = js_demo fgjs #js_demo_SOURCES = js_demo.cxx #js_demo_LDADD = -lplibjs $(base_LIBS) $(joystick_LIBS) -lplibul #fgjs_SOURCES = fgjs.cxx jsinput.cxx jsinput.h jssuper.cxx jssuper.h #fgjs_LDADD = -lplibjs $(base_LIBS) $(joystick_LIBS) -lplibul \ #-lsgprops -lsgmisc -lsgio -lsgdebug -lsgstructure -lsgxml -lz But still a problem with missing -llibwinmm ... So putting this back as -lwinmm in 'configure', and clearing the environment - ie close cygwin windows, then re-open it again - then doing just - $ export CPPFLAGS=-DNOMINMAX $ ./configure -prefix=/fg-cvs $ make AND fgfs.exe LINKED - Making all in Main make[2]: Entering directory `/home/GeoffMcLane/FlightGear-0.9-cvs/source/src/Main' g++ -DPKGLIBDIR=\/fg-cvs/share/FlightGear\ -g -O2 -D_REENTRANT -L/fg-cvs/lib -L/usr/local/lib -o fgfs.exe boot strap.o ../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a ... etc, etc, etc ... ../../src/Environment/libEnvironment.a -lsgroute -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound -lsgserial -lsgstructure -lsgenvironment -lsgthreads
[Flightgear-devel] Re: FlightGear/SimGear dsp/dsw files
Hi, I too had some delays - mainly due to house guests cutting down my computer time ;=)) Thanks for the addition of config.h-msvc8 to CVS. I wonder why it was not called either just config.h-msvc, since it WORKS with ALL version of MSVC, or at least config.h-msvc6, as it WAS called before ... but no problem ... what's in a name ;=)) And is there any need now to keep config.h-msvc6.in? Or does cygwin somehow need this? I think not ... Also noted - #define ENABLE_AUDIO_SUPPORT 1 has been added, although it had already been defined later in the file, with - #ifndef ENABLE_AUDIO_SUPPORT #define ENABLE_AUDIO_SUPPORT #endif but luckily I had put this define, within an #ifndef so no warning of a 'redefinition' ;=)) Also, since presently every usage in the source uses - #ifdef ENABLE_AUDIO_SUPPORT and NOT #if ENABLE_AUDIO_SUPPORT then the defining of it as equal to 1 does not make sense, but it is no problem either ... Further - #define ENABLE_THREADS 1 has been added, making 'threads' a DEFAULT choice. I had left this out, since it seems it should be a user OPTION, thus added only as a MSVC define, ONLY IF DESIRED BY THE USER ... but, why not? pthreads is a quick easy download, and install ;=() just one MORE thing to do ... Have now had a chance to download, and install 'Express' MSVC8 ... and have been reading all the other posts on this ... I had some initial problems because I had installed and tried earlier Beta versions, but someone in MS has written a nice (unsupported!) clean-up tools ... Still have not got the Platform SDK exactly right ... seems missing GL/glut.h, for example, but on this occasion chose to go the freeglut way ... thus was able to compile FlightGear, using the new projects/VC8 SLN/VCPROJ files, after considerable modification to suit my local environment, mainly folder/directory arrangements ... I did the whole gambit in MSVC8 - PLIB, OpenAL, pthreads, zlib-1.2.3, freeglut, SimGear/source, and FlightGear/source ... all were the latest, circa 4/5 April, CVS updates, except zlib, which comes only in tar.gz form ... ... do not know about MSVC8, since I have yet to BUY, and use this extensively ... There is almost no difference between the express and the professional version. ... For one thing, the express version has NO resource editor ... luckily FlightGear uses none, like most of the dependent projects, so this is not a particular drawback for this project, but would severely inhibit a native WIN32 build ... I wonder what else is 'broken' in the free 'express' version? ... Naturally I used the newly provided VC8/SLN|VCPROJ files, but feel you have just as many 'fix-ups' to be done in these, as with using the DSW/DSP files, and NO automated process to 'fix' them, as they inevitably become 'stale' ... This is no problem while we have an ACTIVE, AVAILABLE and WILLING group of developers using MSVC8, provided they REMEMBER each time a SG/FG Makefile.am is CHANGED, these files will have to be MANUALLY changed in CVS ... While the use of am2dsp.pl has its drawbacks as well, at least it is an 'auto' process ... I am still unsure exactly what 'errors' come from the use of DSW/DSP conversion ... I have had none ... something was said about dependencies, size and compile times ... but no real details ... just implied problems ... FUD factor 7.5? ;=)) Ok, we now have VC8 project files in SimGear and FlightGear, but there are NONE in PLIB, freeglut, pthreads ... those in zlib FAILED to work at all ... so, IMHO, it still seems the DSW/DSP set are the BEST BET for all versions of MSVC, all projects ;=)) I think am2dsp.pl, and its am2dsp.cfg files could be massaged quite a lot, and these would automatically produce a consistent, automatic, functional set of build files, FOR ALL VERSIONS OF MSVC ... given some 'agreed' folder structure ... I have done some of that massaging for myself, but my sense is that some of the MSVC developers do not LIKE this system, so have never tried to put forward the massive improvements that could be done ... Like providing configuration values that advised your exact folder structure, and producing DSW/DSP files to match ... but this also means 'distributing' the actual perl script, and the user having some perl installed to run it ... Like separating the Debug and Release more, like some of what was done recently, etc, etc, etc, ... As you are no doubt aware, MSVC7.1 will NOT accept MSVC8 files, so the most 'compatible' is to provide MSVC6 build files that CAN be used by ALL VERSIONS ... and I really dispute that this 'breaks' some sense of dependency, or significantly 'slows' the compile ... It has always been true that it seemed somewhat senseless to put all the generated object files in separate 'library' folders ... as is done by the Makefile.am system, and this significantly adds to the DSP size, just adding all these folder names ... and the 'new' VC8 files have straightened this out a little ... But even now, again I am puzzled by the
Re: [Flightgear-devel] FlightGear/SimGear dsp/dsw files
As you know, the file NEEDED to compile FG is config.h. Several years back this was COPIED from config.h-msvc6, like what is done in many other open projects ... this is common ... people get used to this ... Of course, they can be very puzzled why, unless they are also quite familiar with the *nix, and cygwin 'automake' environments ... that some header.h.in is used to generate a header.h, with corrections, depending on what was found during a header file search ... but, ok, that can be understood ... Another point I was going to make about the newer config.h-msvc6.in is that is does contain an AUTOMAKE macro - @VERSION@ - If you want to KEEP this for use with cygwin, that is fine. Then why not put back a config.h-msvc6, just for the MSVC environment, with NO automake macro ... If you run ./configure, the config.h-msvc is generated from config.h-msvc.in ( you need cygwin installed ). Why would cygwin need config.h-msvc generated from config.h-msvc.in? cygwin generates config.h, the main file, from config.h.in, no? Why would cygwin need to 'generate' an intermediate file that it does not use ... plays no part in a cygwin build? ... And even the suggested 'run ./configure' would lead you to a cygwin mess ... just like in the MSVC environment, the folder where you loaded certain things IS VERY important, thus you need to run, something like - $ ./configure -prefix=/fg-cvs to generate the correct folder placement of items ... But this is all in the cygwin environment. Nothing really to do with raw a MSVC compile ... I hope it is not suggested a MSVC user download and install cygwin JUST to generate config.h-msvc so MSVC can use a custom make step to COPY this to config.h ... ;=)) * They don't work as is. This is agreed, but they are a good START ;=)) Due to many things, like where did you download PLIB, Simgear, zlib, OpenAL, etc, ... almost nothing would work out of the box, including any SLN/VCPROJ files, if provided ... unless you 'conform' 100% to the folder structure chosen by the SLN/VCPROJ providers ... And for example, I note from Olaf's site, the addition of pthreads, and freeglut ... other folders locations that would be important ... that must be 'correct' to suit the given SG/FG SLN/VCPROJ files ... * The dsw files are for VC6. Visual C 6 does not compile FlightGear (any more). As recently as a few months ago, I assisted a person, (offline) to compile using MSVC6. It does require some code 'work' to do this, but it is POSSIBLE ... none of this has been put forward as a 'change' in the CVS code ... so why should you care? Yes, you can suggest they download other 'tools', new 'tools' etc ... but also why not let them use what they have ... * They don't even work for newer Visual Studios (Dependencies are broken: Microsofts Fault, not our's) Not sure how this is related to removing the DSW/DSP file, or what is exactly refered to here. If it is refer to the fact that MSVC7.1, and perhaps 8, no longer seem to keep as good a automatic track of dependencies as good old MSVC6, then, as a 'developer' you get used to using 'remake all' ;=)) actually, I more frequently use the 'batch mode' ... But why is this any reason for removing this set of DSW/DSP files, automatically generated? * IMHO No developer uses them. As I suggested, 'developers' tend to find their own way ... have their own preferences, etc ... it is for the new, first time users that I want to encourage to 'become' developers that I feel for ... that need help ... These DSW/DSP files can be automatically generated by am2dsp.pl, enhanced fractionally a few months ago by Fred, using am2dsp.cfg, thus can be the first indication that a new file has been added, or some source removed ... or you can read/view the raw Makefile.am files directly ... They do work for MSVC7.1 ... it provides a good 'conversion' to its new xml format, leaving the DSW/DSP alone ... do not know about MSVC8, since I have yet to BUY, and use this extensively ... I have tried a few times with the 'express' (free for now) version, and it did a similar 'conversion' ... This is good in that in a CVS update, you can quickly compare your old with the new, to see if you need to update your SLN/VCPROJ files ... if that is what you use ... I would vote for including Fred's VC7.1 and/or my VC8 project files from http://www.oflebbe.de/oflebbe/FlightGear. There are surely some pitfalls I too have MSVC7.1 *AND* MSVC6 build file on my site - http://www.geoffmclane.com/fg/ - this is purely a factor of how frequently you 'update' your site ... or the cvs, if put in cvs. Sure Fred and Olaf want to move on ... then I agree perhaps the SLN/VCPROJ files should also be added to the CVS source, but that is no reason to delete the auto-generated, partial, incomplete, DSW/DSP files from CVS ... let all forms live ;=)) So what am I suggesting? Simply, that a config.h-msvc file be returned to cvs, so the current custom step in am2dsp.cfg works! And that, that
Re: [Flightgear-devel] FlightGear/SimGear dsp/dsw files
Just a small point, but it could bother some new people ... when you load MSVC7.1 using the FlightGear.dsw (and dsp), you can be blocked from a compile by a custom step, which presently fails ... The am2dsp.cfg file contains a custom - # Rule to create config.h which gets included when am2dsp.pl is run, but at present this custom step tries to copy from - config.h-msvc to config.h This is certainly what it used to be called, when I last updated it in July 2003, but quite some time ago this file name disappeared, and was replaced with - config.h-msvc.in same file contents however ... Could we either - (a) adjust the FG am2dsp.cfg file to reflect this changed name, or (b) put the file back as config.h-msvc, as it was originally. It is agreed most of us no longer depend on the DSW/DSP provided, since perhaps like me, we update our SLN/VCPROJ files when new files appear in a CVS update ... but new people probably still commence with these old file ... and this 'error' does block a compile ... Regards, Geoff. EOF - fg-38.doc _ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: Curtis - small change of UFO.cxx possible?
What an excellent idea ... it allows UFO speed
adjustments with g/G keys ...
Here is a tiny tested patch -
--- c:\FGCVS\FlightGear\source\src\FDM\ufo.cxx Thu Mar 02 12:18:14 2006
+++ source\src\FDM\ufo.cxx Sat Mar 11 13:20:40 2006
@@ -94,6 +94,9 @@
// the velocity of the aircraft
double velocity = Throttle * 2000; // meters/sec
+if (globals-get_controls()-get_gear_down()) {
+ velocity = Throttle * 10;
+}
double old_pitch = get_Theta();
double pitch_rate = SGD_PI_4; // assume I will be pitching up
Just 3 lines ...
It also overcomes another bothersome minor 'problem' ...
frequently, when I start FG with the UFO, by the
time I 'see' the scene graph, the UFO is miles
away from KSFO ... even when my joystick throttle
slider is on ZERO ...
It seems some residual value is in 'throttle' ...
I can clear it, if I remember to 'blip' the throttle
late in the FG load, but this patch make this
less of a problem ...
re: GNU utilities for Win32
This patch is done with the 'diff.exe', with the
option -u ... you can obtain the zip file from -
http://unxutils.sourceforge.net/
It contains a great list of ported to WIN32
GNU utilities, and does not require any
special DLL, like cygwin ...
I hope this small patch can be added to
ufo.cxx cvs ...
I think Gear down/up is better than
flaps ... I've heard ALL UFO's have 'gear',
but do not need 'flaps' ;=)) but either would
do ...
I know, the UFO probably does not have
'gear' either, since it also 'flies'
underground ;=)) good for checking for mineral
deposits below mountains ...
Regards,
Geoff.
EOF - fg-37.doc
_
Don't just search. Find. Check out the new MSN Search!
http://search.msn.com/
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
