[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] 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] 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=1&q=cheap+flights&FORM=HM ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[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 and ... 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 You could probably modify this to "al.h", then MSVC would do a 'local' search ... 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] 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] 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] 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 , 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 2>log.txt 1>&2 ... 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, 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] 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] 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: fgrun WIN32 double quoted path bug
Hi Fred, Yes, it is hard to notice, since this will work - --fg-scener"y=c:\my pa"th and only in the very, very unlikely case of say a path like 'my path a' would fail with - --fg-scener"y=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-scener"y=c:\mypa"th 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 #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
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