[Flightgear-devel] Re: openAL compilation problem
Hi WIN32 developers, I too have had BIG PROBLEMS with compiling OpenAL CVS with MSVC7.1 - maybe this will eventually be cleared up by the OpenAL developer group ... maybe NOT ;=(( Part of the problem, is that for no particular good reason that I see, in WIN32 they, the OpenAL group, decided to implement these as DLLs, rather than Static libraries, as they are in other environments ... Meantime, to get FlightGear LINKED, I downloaded, and installed the OpenAL (WIN32) SDK 1.1 binaries, and used those for the SimGear/FlightGear COMPILE and LINK ... This presented a small problem, in that, in this SDK, which will install in C:\Program Files\OpenAL 1.1 SDK\ by default, the 3 headers needed, al.h, alc.h, alut.h have been placed in an 'include' directory, whereas SimGear expects them to be in an 'AL' directory ... it uses #include AL/al.h and AL/alut.h ... Ok, so I created an AL directory, in the SDK folder, and copied them into there ... simple ... That nearly works ... unfortunately alut.h also includes al.h by just using #include al.h You could probably modify this to al.h, then MSVC would do a 'local' search ... al.h only searches 'include' directories ... This meant I had to provide BOTH 'additional include' folders, namely 'C:\Program Files\OpenAL 1.1 SDK' and 'C:\Program Files\OpenAL 1.1 SDK\AL' to the SimGear compile ... but, Bob's your uncle ... I got a CLEAN LINK of SG and FG ... A little more can be read about this on my page - http://geoffmclane.com/fg/fgfs-018.htm Down at the bottom, under 'Some other details:' I have given the additional dependencies, and directories of FG AND SG that I used ... Regards, Geoff. _ View 1000s of pictures, profiles and more now at Lavalife http://lavalife.com.au ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Compiling with cygwin
A little OT, I would ALSO like to help in WIN32 with cygwin builds, and have begun to try cygwin, but hit problems with my first try, with PLIB ... After ./autogen.sh and ./configure (boy, that seems a SLOW process), when I then run the make, it exits with - $ make Makefile:328: *** missing separator (did you mean TAB instead of 8 spaces?). Stop. Geoff [EMAIL PROTECTED] ~/FG099/PLIB I don't know! Did I ;=)) Of course, I can MANUALLY fix the Makefile line(s), but I should NOT have to do that!!! Maybe some cygwin WIN32 developer could open up a direct email with me, and give me some quick pointers ;=)) Regards, Geoff. _ Search the Web for cheap flights http://search.ninemsn.com.au/results.aspx?rf=1q=cheap+flightsFORM=HM ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: SimGear compile dying in MSVC6
Hi Sam, Although I have personally abandoned MSVC6 in favour of MSVC7.1, ALL should be possible with MSVC6 - again, my pages - http://geoffmclane.com/fg has lots of information on compiling with MSVC6 ... trials and tribulations ... Maybe I too will try it again, but AFTER I experiment with cygwin, my next trial ... ;=)) but I know of another recent person that has compiled, and run FG using MSVC6 ... he too had problems with openAL, but got through PLIB, SG and FG ;=)) Best of luck ... Geoff. _ View 1000s of pictures, profiles and more now at Lavalife http://lavalife.com.au ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: SimGear compile dying in MSVC6
Hi Sam, Curt wrote : simply too old and buggy While I might agree with the AGE, circa 1998, 7 years might be the life expectancy of a compiler ;=)) I do not think I could characterise it as 'buggy' ... quirky, kinky, and as I used below, 'blind' ... or simply lacking in SOME newer C++, albeit now 'standard', features ... Getting quite frustrated with getting any further with my new-for-me cygwin build, I decided to light up my crusty, trusty?, MSVC6 once again, and check out this small problem ... It is simple!. The suffix LL is NOT supported by MSVC6, but IS supported by MSVC7 ;=() Do a search for 'Suffix L' in your HELP (last was Oct 2001), and select 'C++ Integer Constants' to read more on this ... You will note the ONLY 64-bit integer-suffix listed is i64 ... In my MSVC7.1 help, same page, it shows i64 AND LL! Using HEAVY switch compile code, you could change the little block of code, to a whole block of code as follows - #ifdef _MSC_VER #if _MSC_VER = 1200 // msvc++ 6.0 x = ((x 8) 0x00FF00FF00FF00FFi64) | ((x 8) 0xFF00FF00FF00FF00i64); x = ((x 16) 0xi64) | ((x 16) 0xi64); #else // !#if _MSC_VER = 1200 // msvc++ 7.0 x = ((x 8) 0x00FF00FF00FF00FFLL) | ((x 8) 0xFF00FF00FF00FF00LL); x = ((x 16) 0xLL) | ((x 16) 0xLL); #endif // #if 6.0 or greater, 7.0 #else // !#ifdef _MSC_VER x = ((x 8) 0x00FF00FF00FF00FFLL) | ((x 8) 0xFF00FF00FF00FF00LL); x = ((x 16) 0xLL) | ((x 16) 0xLL); #endif // #ifdef _MSC_VER y/n Of course you could just change the two lines - x = ((x 8) 0x00FF00FF00FF00FFLL) | ((x 8) 0xFF00FF00FF00FF00LL); x = ((x 16) 0xLL) | ((x 16) 0xLL); to x = ((x 8) 0x00FF00FF00FF00FFi64) | ((x 8) 0xFF00FF00FF00FF00i64); x = ((x 16) 0xi64) | ((x 16) 0xi64); I tried various #define-s and typedef-s to fix this, but did not find one that WORKED ... maybe you can ... which can then be added to the _MSC_VER switch at the top of the file ... This is a LOCAL change you will have to MAKE ... I think I can assure you, at least I believe, such messy switch coding will NOT be added to the base code, just to support, a now old, known to be quite 'blind' C++ compiler, namely MSVC6 ;=)) Also, I should TRY to add this to my MSVC6 web pages of woes ... Have fun ... Regards, Geoff. PS: Thanks Kevin, for the offline email pointer - http://www.flightgear.org/Docs/Tutorials/fg_cygwin/fgfs_cygwin.pdf I will read this, and yes, I am using the latest CVS, as always, and not a 'stable' tar ball ... but do not see how this 'makefile' problem could be that ;=)) EOF _ MyCareer.com.au: Visit the NEW Salary Survey http://www.mycareer.com.au/salary-survey/?s_cid=203697 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] MSVC7.1 and CVS up 0.9.9-pre3
Hi, A CVS update, 13 Nov, 2005 - PLIB, SimGear, FlightGear/data, and FlightGear/source ... Just to confirm that I had few problems building and running 0.9.9-pre3 with MSVC7.1 in WinXPSP2 ... I had to delete puAuxList.cxx from the PLIB build, and src/Time/sunpos.cxx/hxx from FlightGear ... but no other fatal errors ... I only had time to try the default Cessna, the 747-100, and for the first time, the Bell206, but could not get it to lift off - power up ... perhaps the throttle mappings to my MS Sidewinder joystick were wrong? I timed the build ... all in under two hours, even with the corrections ... the full timed update text can be read here - http://geoffmclane.com/fg/fgfs-018.htm I also uploaded the release binary, in a zip file - see PS: at bottom of the web page ... As always, thanks for a great flight simulator ;=)) Regards, Geoff. EOF _ SEEK: Over 80,000 jobs across all industries at Australia's #1 job site. http://ninemsn.seek.com.au?hotmail ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] MSVC7.1 CVS Oct 25 - 2 compile errors
Hi, My CVS update of Oct 25 pulled in lots of 'changed' files, and had two problems with the compiles. They were simple fixes ... SG/source - fastmath.cxx Had to put the include of fastmath.hxx in front of #include simgear/constants.h, since constants.h also sucks in math.h ... through compiler.h ... fastmath.hxx correctly defines _USE_MATH_DEFINES, under a _MSC_VER switch, before including math.h, which works fine ... This is to define a value for M_LN2 ... this error has come and gone, over YEARS ... sometimes I would just drop in a define ... FG/source - tacan.cxx I made this fix some weeks back, but forgot to mention it ... Talk about a 'sanity check' ... the line MSVC dies on or about line 368 - if (frequency_khz 9620 and frequency_khz = 12130)return frequency_khz/100; I added the following - #ifdef _MSC_VER if (frequency_khz 9620 frequency_khz = 12130)return frequency_khz/100; #else // !#ifdef _MSC_VER if (frequency_khz 9620 and frequency_khz = 12130)return frequency_khz/100; #endif // #ifdef _MSC_VER y/n but maybe the author, Vivian, would not mind using '', instead of 'and' ;=)) Assume gcc compiler accepts '', as well as 'and' ... FG/data Lots of new files, that I had read about here ... On running FG, it exited, with the last few console messages - Adding subsystem lighting Initializing OpenAL sound manager Audio initialization failed! Adding subsystem fx ATC Display ATC Manager WARNING - INVALID type found in C:/FG0981/FlightGear/data/ATC/default.atis WARNING - INVALID type found in C:/FG0981/FlightGear/data/ATC/default.tower WARNING - INVALID type found in C:/FG0981/FlightGear/data/ATC/default.ground WARNING - INVALID type found in C:/FG0981/FlightGear/data/ATC/default.approach From file sounds sample = C:/FG0981/FlightGear/data/ATC/default.wav Fatal error: Failed to load wav file. Each of these files exist in the ATC folder ... Abandoning my own OpenAL compile from CVS source, I downloaded some new, mid Oct, OpenAL WIN32 binaries, with windows installer included, removed my hand-built stuff, and bingo, the sound works again ... but still get the above WARNINGS ... from current console output - Adding subsystem lighting Initializing OpenAL sound manager Adding subsystem fx ATC Display ATC Manager WARNING - INVALID type found in C:/FG0981/FlightGear/data/ATC/default.atis WARNING - INVALID type found in C:/FG0981/FlightGear/data/ATC/default.tower WARNING - INVALID type found in C:/FG0981/FlightGear/data/ATC/default.ground WARNING - INVALID type found in C:/FG0981/FlightGear/data/ATC/default.approach From file sounds sample = C:/FG0981/FlightGear/data/ATC/default.wav Opened word data file ATC/default.vce OK... ATC Transmissions Current Unix calendar time = 1130405441 warp = 0 Current GMT = 10/27/2005 9:30:41 ATC Dialog System AI Manager Am at present ignoring these WARNINGS ... but wonder what is the INVALID type found ... and why? OT a little - Obtaining the console output is quite difficult in windows ... you must jump on the [pause] key at the right time, else what you want to see will have scrolled out of my already enlarged console buffer ... I have tried every which way to redirect this output ... with things like log.txt, or 2log.txt 12 ... but NOTHING seems to work ... it seems the sg_log() initialisation undoes the command line redirection? Do other windows users have this problem, or has someone solved how to re-direct the output to a file? As usual, hope this helps ... at least the MSVC, windows users Geoff. EOF _ MyCareer.com.au: Visit the NEW Salary Survey http://www.mycareer.com.au/salary-survey/?s_cid=203697 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RE: Two problems - 1 easy and 1 hard! - in XP using MSVC7
Hi, Thanks LeeE (Debian) and Oliver C. (Linux) for your --fog-disable --visability=12 tries ... this is almost, I say ALMOST, enough to get me to switch to a *nix system ;=)) =IF= I had got my no fog, maximum visibility, and disabled clouds, running, one of my next questions would have been - Why is it ALWAYS so dark in the distance? ;=/ This can be at noon, and it is the same all around ... and even if the sun is more over the distance scene, morning or evening, it is ALWAYS rendered black in the distance, except when fog is enabled ... then it is rendered all white ... ;=)) Judging by the size of the 'squares' on the ground, I guess Oliver's image must be from about 4 feet, and when I climb to this height I get a TOTAL BLACK scene below me ... only when I descend does the ground become lighted ... This is with the default visibility, whatever that is, and no fog ... of course, if I set the visibility to 6m, the MAXIMUM I can use without getting a memory ABORT, then looking straight down, the ground is lighted, but the distance is BLACK ... It definitely feels as if the lighting effect is taken from the position of the viewing aircraft, and certainly not from the actual position of the sun ... But, for the moment, I must settle for my windows less memory ;=(( Regards, Geoff. PS: I have put some images on this page - http://geoffmclane.com/fg/fgfs-017.htm since it is quite hard to explain ... It also includes my OpenAL change, and other things ... see separate post ... EOF _ REALESTATE: biggest buy/rent/share listings http://ninemsn.realestate.com.au ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RE: Two problems - 1 easy and 1 hard! - in XP using MSVC7
Hi, I guess I should write MSVC7.1 ;=)) I am using the 2003, version 7.1.3088 ... Have downloaded beta 2005, but still to try this ... Thanks for the heads up about the 120km limit of the renderer, Harald ... I will keep that in mind ... I presume this is a constant defined in FG/SG/PLIB/?? somewhere ... And thanks Andy, for the pointer - http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx This explains it all ... a maximum of 2GB of process memory, and 2GB for system memory, unless you add /3GB to boot.ini *AND* reset the exe image using Editbin.exe to set IMAGE_FILE_LARGE_ADDRESS_AWARE ... which seems quite a lot of effort ... to gain an extra GB ... but worth keeping in mind ... I had already experimented a little with the virtual memory settings and discovered the 4GB LIMIT! And perhaps now see why FG did NOT allow me to use my 20, or even 12 ... even though windows had memory for starting other memory hungry processes ... Word for example ... It also perhaps explains why Word will also politely reject say a paste operation, when copying in a large site from IE ... by large here, I mean a site that takes lots of memory to contain ... I can get a MEMORY ABORT ... it is a shame it does not seem to set a memory error message that perror(...) sees ... by just be removing the fog (--fog-disable), even with the default visibility ... which is? So while the renderer might have a 120km (~75 miles) limit, it is further reduced by the FOG ... at present, through repeated experiments, the most I can push the fog back is 45 miles (72420m) ... 50 miles produced an ABORT after quite a number of minutes of flying ... aka tile loading ... We could attack the tile manager ... but not suggesting this literally, since it already does a good job ... it could encase its 'new' in an exception handler, and 'know' it is requesting too much memory ... and if a distant tile, that it 'knows' can not really be rendered, forget it, output a warning, or, remove (free) some of the non-visible behind tiles ... but I agree, this is, perhaps, way too complicated ... Also, if as Harald reports, the renderer has a hard coded limit of 120km, then, at least, IGNORE a user request for more ... what would be the use in loading tiles out-of-range of the renderer, if there is such a limit? The whole aim here is to produce an application that withstands ALL user parameters entered ... especially --fog-disable ... If I do not want REALISM, I want to 'see' as far as possible ... then the application should try to oblige ... IMHO ... Simply, I would prefer FG fly on, and not ABORT, just because it passed the 2GB of process memory, in WIN32. It is further assumed unix systems do not have these constraints ... or a different set of memory problems ... I would certainly be pleased if a *nix system user could try - --fog-disable --visibility=12 Is no one else interested in 'seeing' as much of the world as possible, as clear as possible, without fog-blur? aka realism ... Anyway, I am happy, now I know the LIMITS, and will try to work, quietly, within these constraints ;=)) Regards, Geoff. PS: I only get board messages in digest (batch) mode, so may be behind what has been subsequently posted ;=() _ SEEK: Over 80,000 jobs across all industries at Australia's #1 job site. http://ninemsn.seek.com.au?hotmail ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Two problems - 1 easy and 1 hard! - in XP using MSVC7
Hi all,
Last CVS update Oct 19.
1. The Easy fix
When trying --airport=LFPO, after downloading, and
installing the required scenery ... FG exited with -
Adding subsystem gui
fgtzfile_read(): : Invalid argument
Timezone reading failed
in the console ...
This turned out to be the usual file line ending problem ...
mine has the 'normal' WIN32 0x0d, 0x0a, ending,
and could be solved by 'fixing' the zone.tab file, or, as I
would suggest, a small 'fix' in SimGear, timezone.cxx ...
Changing the line 104, in timezone.cxx -
while (!((infoString[i] == '\t') || (infoString[i] == '\n'))) {
to a more robust, cross platform search ...
while (!((infoString[i] == '\t') || (infoString[i] == '\n') ||
(infoString[i] == '\r'))) {
and all is well ...
Looking further into this, I note that the zone.tab in the Fred B.
binary release (from fgsetup-0.9.8a.exe) is in unix format!
Then why does my CVS update file have 0x0d,0x0a? I
am sure it is unix format on the server, is it not?
I delete my local old copy (22/10/2000), and did another
update, and it returns, with 0x0d,0x0a. I have read
somewhere that some FTP clients handle, cause this
change, transparently!!! If true, another reason to
adjust the code, rather than the file each time ... ;=))
Maybe there is a CVS command to inhibit this
change, if that is where it happens ...
As part of this investigation I note that
fgInitTimeOffset(), the service that uses the information
from the zone.tab load, is called twice ... first as part of
fgInitSubsystems() (idle_state == 7), with the code comment -
fgInitTimeOffset(); // the environment subsystem needs this
and then again in idle_state == 8, with the code comments
// Initialize the time offset (warp) after fgInitSubsystem
// (which initializes the lighting interpolation tables.)
fgInitTimeOffset();
This does not cause any problem, since the loader is
quite tidy in deleting the previous allocations ...
And for those wondering why this does not occur with
the default KSFO, that particular Los_Angeles line in the
tab file has a comment, thus an extra tab, which is
discarded ...
2. The Hard find
I am getting an exception ABORT again, and again, especially
since I changed to using LFPO ... the console does not help
much, log level debug, the last lines just showing -
Unknown exception in the main loop. Aborting...
Possible cause: No error
Deleting a sample ... (written another 4 times!)
Actually this could be two different ABORTS. One is
during the start-up, before the flash fades, which I suspect
is due to one of my system.fgfsrc file 'disable' lines, and the
other is after a few, plus minutes of running ... I know not
why ...
I am still trying to track this/these down ... are any other
Windows XP SP2 - MSVC7 users getting this/these? Any
ideas welcome ... I would like to get back to smooth
flying ...
Regards,
Geoff.
OT1: It has been a few years since my last post ... but
have been reading here, and playing with FG/TG, now and then ...
Usually, when there is a MSVC question, that I could
add to, Fred B. is so fast to answer ... Thanks Fred ;=))
OT2: Also for quite a few years now, I have been adding
my FG experiences to my site - it all starts at -
http://geoffmclane.com/fg
Excuse the long, rambling, quite messy, site ;=))
The latest build, and these ABORTS are here -
http://geoffmclane.com/fg/fgfs-014.htm,
and it continues, a follow-on ...
http://geoffmclane.com/fg/fgfs-015.htm
if you can stand the pain ...
EOF
_
SEEK: Over 80,000 jobs across all industries at Australia's #1 job site.
http://ninemsn.seek.com.au?hotmail
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Two problems - 1 easy and 1 hard! - in XP using MSVC7
Thank you, Harald for your quick reply ...
1. Easy fix - line endings
Glad you could confirm my CVS check out ... but the
suggested code fix takes care of it, which ever line
endings there are in zone.tab ;=))
2. Hard find - ABORT
Thank you for the Debug menu pointer ... I had not found
MSVC very good with exceptions, in the distant past,
but it has really improved ...
Trapping the exception, and returning to the debugger, the
Call Stack showed, in part, the simple answer ...
FlightGear.exe!_nh_malloc_dbg(unsigned int nSize=1, int nhFlag=3, int
nBlockUse=1235168, const char * szFileName=0x0012d9ec, int nLine=1242460)
Line 267 + 0x7
FlightGear.exe!_CxxThrowException(void * pExceptionObject=0x0012d8fc, const
_s__ThrowInfo * pThrowInfo=0x00e95db0) + 0x39
FlightGear.exe!std::_Nomemory() Line 10
FlightGear.exe!operator new(unsigned int size=73056) Line 15
...
FlightGear.exe!FGTileMgr::update(SGLocation * location=0x201ac898, double
visibility_meters=20.000) Line 437
And of course, passing the exception back to FG, I end up
at the lines in bootstrap.cxx -
} catch (...) {
cerr Unknown exception in the main loop. Aborting... endl;
perror(Possible cause);
}
The console last few lines showed, confirming the call stack -
FGTileMgr::update()
State == Running
Loading tile
C:/FG0981/FlightGear/data/Scenery/Terrain/e000n40/e001n47/2974291
token = OBJECT_BASE name = 2974291.btg
So these ABORTS were a SIMPLE case of OUT-OF-MEMORY, of a
certain type ... This is the very first time I have found
Windows wanting in the memory allocation area ... I
thought the virtual memory was virtually unlimited ;=))
well, depending only on settings, and HDD size ...
So, maybe I can increase the swap file size, and
certainly REDUCE my very unreasonable visibility,
20 meters, or BOTH ...
Note, Windows is not completely out of memory,
since I was able to open Word, and commence writing
this, while still in the debugger ... with several
other windows open ... ???
Removing my unrealistic 20 from my system.fgfsrc
file, thus allowing the default visibility, and I could
fly around, with fog, and sky-blend, all day ;=))
I took off from Orly, flew generally NNW, and ended up
at Lands End, with some help from Google Earth ...
followed the southern coast around to Manston,
then left into Heathrow, over London, then
took about a 160 track, hit the French coast at 49 48'N,
0 30'E, adjusted to 135 track, and back to Orly, after
some other adjustments ...
Over 2 hours of UFO flying ... sometimes at many times the
speed of sound ... stoping here and there to look around,
identify an airport, etc, and not a single ABORT ...
Checking my virtual memory options, I note it has
a maximum size of 1536MB, with 1534MB currently
allocated! ... since I have 30 plus GB left on the
drive, maybe I could increase the maximum ... and be
flying in clear air, with extreme visibility ...
but will experiment with that another day ;=))
Thank you ... thank you ... thank you
I have certainly learned a lesson about push the
parameters ... if you want clear air and long distant
vision, be careful about MEMORY ABORTS ;=)) I kind
of knew it had something to do with my system.fgfsrc
preferences ...
So, the problem is sort of solved ... back to
quiet flying ... thanks again
Regards,
Geoff.
EOF
_
REALESTATE: biggest buy/rent/share listings
http://ninemsn.realestate.com.au
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: fgrun WIN32 double quoted path bug
Hi Fred, Yes, it is hard to notice, since this will work - --fg-scenery=c:\my path and only in the very, very unlikely case of say a path like 'my path a' would fail with - --fg-scenery=c:\my path a the space being 'outside' the quotes ... I think the win32 C/C++ runtime parser, that splits the command line into the char **argv, array, removes the double quotes ... I guess ... because FG does not complain of a bad option ... except in the 'exceptional' case ... Also, thank you and Norman, for the pthreads pointer ... which, I had thought was part of cygwin ... I have now CVS's this source, and when I get time, ;=)) will include this in my 'arsenal' ... then maybe I can get some of my TerraGear components to 'fork' ... rather than using my current 'work-around-s' ... One other small fgrun 'feature' I found, is that, if I back up to page[0], there is a delay while it re-loads apt.dat.gz, when I go 'forward' again ... have not yet looked at why ... but it is not a real problem ... and I am a few days behind in cvs terms ... To Jorge, yes, but not ONLY to run another FG ... ;=)) A thought-only, at this stage, is to say change aircraft, or FDM, and pass the new configuration back to the running FG ... the 'launcher' becomes 'controller', or dynamic re-configure-er, in some way ... way into future? ;=(( Or for fgrun to now launch Atlas ... or ... ??? But this is more about the win32 only line - WaitForSingleObject( pi.hProcess, INFINITE ); in the run_win32.cxx implementation, and does not influence, or change the run_posix.cxx port ... which uses waitpid( pid, status, 0 ); on 'parent' fork, and execv( path.c_str(), pt ); on the 'child' ... and thus 'depends' on what these functions do ... I can see, say a preference item, like - [x] Modal Dialog, while FlightGear is running ... perhaps only appears in the win32 port ... the default can be on ... thus not changing fgrun's present action, but gives more 'options', to different users ... Or, even add a [Close], or [Hide] button, to the modal window ... then the preference(s) could be on that dialog, like - (o) Wait until FlightGear exits, or ( ) Do not show this modal dialog again. or ( ) Show this dialog for [30 ] seconds only. In the fltk window win32 implementation, I detected some exit problems, if I just 'big-red-X-ed' the modal dialog ... which got me 'looking' at some of this in the first place ... it seems 'wrong' not to provide some 'polite-exit' to this modal situation ... aside from when FG exits ... My particular case was, now that FG was running, I simply wanted to check, review, my command options ... like FG is 'beeping', didn't I select disable sound? ... etc ... not stare at a locked modal dialog situation ... Enjoy ... Geoff. _ Update your mobile with a hot polyphonic ringtone: http://fun.mobiledownloads.com.au/191191/index.wl?page=191191polyphonicringtone ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] fgrun WIN32 double quoted path bug
Hi Fred, and others ...
First I would say I LOVE fgrun ... my hat off
to those in our community who 'remember' all the
130 plus command line options for FlightGear ... yet
they are part of its 'power' ... as well as giving
a beautiful preview of the aircraft ... fgrun takes the
angst out of changing switches ...
Before 'running' FlightGear, in run_win32.cxx,
the Wizard::run_fgfs(string args) function
correctly encases the path in double quotes, needed if a
space exists in any of the directory names ... but it
uses the passed args to compute the lengths ... which will
always work for the first 'change' ... but will then
be 'wrong' in the second change to the copy 'line' ...
Here is the patch, in diff format -
40c40
string::size_type pos_fg_root = args.find( --fg-root= ),
---
string::size_type pos_fg_root = line.find( --fg-root= ),
44c44
end_fg_root = args.find( --, pos_fg_root + 10 );
---
end_fg_root = line.find( --, pos_fg_root + 10 );
49c49
string::size_type pos_fg_scenery = args.find( --fg-scenery= ),
---
string::size_type pos_fg_scenery = line.find( --fg-scenery= ),
53c53
end_fg_scenery = args.find( --, pos_fg_scenery + 13 );
---
end_fg_scenery = line.find( --, pos_fg_scenery + 13 );
Without this 'fix' I got things like --fg-scenery=c:\mypath
I wrote a simple service, for another project, to do the
same - it is NEEDED quite frequently in win32 ;=)) - which you
could add/use/modify -
int fg_prefs::encase_arg( string line, string arg ) {
int iret = 0;
string ar = --; // start option argument
string are = --; // to next, if any
ar += arg; // add the current argument/option
ar += =; // add EQUALS
size_t pos1 = line.find(ar); // find, like '--fg-root='
if( pos1 != string::npos ) { // if FOUND
size_t sz = pos1 + ar.size(); // get the arg size
size_t pos2 = line.find( are, sz ); // find next arg beginning
if( pos2 == string::npos ) { // if NOT FOUND
pos2 = line.size();
}
line.insert( pos2, \ ); // pop in the quotes, at the end first
line.insert( sz, \ ); // then at the front of the 'path'
iret = 1; // advise done
}
return iret;
}
You will note I check the find of the 'next', in case it
is the last, or only option, in the args passed ...
I would also be interested in whether my use of 'size_t',
in place of the rather long 'string::size_type' works
in all the ports ...
I use msvc7, in XP, cygwin not installed, so also do not
use pthreads ... I added a switch, HAVE_PTHREAD, for things
like -
#ifdef HAVE_PTHREAD
#include pthread.h
#endif // #ifdef HAVE_PTHREAD
if anyone is interested, or headed this direction ...
I need fgrun to 'return', so I can 'select' other things,
and run (the same or different) FG, with a changed
command ... rather than at present, it shows a modal
dialog, and goes into an infinite wait, until FG
quits ... thus do not need pthreads to compile, run ...
Enjoy ... and thanks again for this nice 'runtime'
GUI ... full of switches, and information ...
Geoff.
_
Find love today with ninemsn personals. Click here:
http://ninemsn.match.com?referrer=hotmailtagline
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RE: --aircraft=ufo in system.fgfsrc is ignored
Hi,
RE: --aircraft=ufo in system.fgfsrc is ignored
*AND*
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
FlightGear/src/Main fg_init.cxx, 1.115, 1.116
Well, it is 'not' ignored, exactly ... it is picked
up in the full scan of the 'command' options, later ... but
that is 'too late' ... the default c172 panel has been
loaded ... and the fact that ufo has no panel does not
'remove' the 'default' panel ...
Yep, you got it now ... my 'just before' meant before the
if( !aircraft.empty() ) else block, not exactly 1 line before
the line fgSetString(/sim/aircraft ... ;=(( I did say
line 343 in my post ...
The 'purpose' of fgInitFGAircrat() is to establish
the 'Aircraft', first from 'command line' , but if none,
then from other places ... so in pseudo like code, it
cascades -
1. set aircraft = fgScanForOption( on command line, argc, argv );
2. #if unix or cygwin, if empty, check for .fgfsrc.hostname file
3. if empty, try HOME .fgfsrc };
4. if still empty - add my patch - check for $fg_root/system.fgfsrc );
ending with, as it does at present, unchanged -
if NOT ( aircraft.empty() ) add it fgSetString(/sim/aircraft,...
else complain/explain No user specified aircraft, using default ;
Sorry I did not make it clear ... I do not
have the 'diff' utility, but here is my 'diff' application
output -
// Compare [C:\FGCVS\FlightGear\source\src\Main\fg_init.cxx]
// Size: 64,642 02/01/05 00:10
// With[C:\FG099\FlightGear\source\src\Main\fg_init.cxx]
// Size: 65,023 26/01/05 05:53
// Time: Left is EARLIER - CHECK!
=
344 ! if ( aircraft.empty() ) {
345 !// Check for $fg_root/system.fgfsrc
346 !SGPath sysconf( globals-get_fg_root() );
347 !sysconf.append( system.fgfsrc );
348 !aircraft = fgScanForOption( --aircraft=, sysconf.str() );
349 ! }
350 !
=
The '!' denotes 'added' lines, like a plus, +, in diff
Those who 'regularly' use system.fgfsrc, like I do,
to control each run of FG, and use 'panel-less'
aircraft, like ufo, have probably been 'adding' this
patch to fg_init for 'years' ;=)) Just trying to
'regularise' and share it ...
It crops up every now and then, with a query like - how can
I remove the panel? ...
Hope this helps ...
Regards,
Geoff.
_
SEEK: Now with over 60,000 dream jobs! Click here:
http://ninemsn.seek.com.au?hotmail
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RE: --aircraft=ufo in system.fgfsrc is ignored
/cloak
Hi,
As always, thank you all for a great flight simulator +++
Have been enjoying it, and your exchange here for 'yonks' ;=))
RE: --aircraft=ufo in system.fgfsrc is ignored
To change a 'feature', one that has been mentioned here many
times, and again recently, place the following code block
into fgInitFGAircraft (in fg_init.cxx), at about
line 343, just before the fgSetString(/sim/aircraft ...
+
if ( aircraft.empty() ) {
// Check for $fg_root/system.fgfsrc
SGPath sysconf( globals-get_fg_root() );
sysconf.append( system.fgfsrc );
aircraft = fgScanForOption( --aircraft=, sysconf.str() );
}
+
If this behaviour change is agreed, then maybe someone who has
tested the patch, can send a diff to Curt, or directly
update CVS ...
In its favour, I would argue this means FG can be run without
a command line, provided FG_ROOT has been set in the
environment, and that seems to me, as it should be ... ;=))
Perhaps the only counter, is that system.fgfsrc is read twice,
but so are others, like .fgfsrc, for other (local) options ...
or system.fgfsrc should .nt. be used for 'aircraft' ?
It certainly paves the way for fgrun to simply write the
system.fgfsrc, and run the binary with a minimum of command
line parameters ... and leaves a persistent file 'trace'
of what fgrun 'requested' of FG ... more info benefit ...
Continue to enjoy ...
Regards,
Geoff.
_
SEEK: Now with over 60,000 dream jobs! Click here:
http://ninemsn.seek.com.au?hotmail
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
