FlightGear - October, 2005 - continued ...

back index

After getting it compiled, October 15, and running - sort of - this is the continuing saga of my October 2005 FlightGear build ... I got a few aborts before my first successful flight ...

Attacking the ABORT!

Just altering two things in my FlightGear/data/system.fgfsrc, and I am back at an abort! I removed changing the log level, and removed the --disable-sound ... even putting back the --disable-sound, and it still ABORTS after a very brief set of console messages -
C:\FG0981\FlightGear>source\Release\flightgear --fg-root=C:\FG0981\FlightGear\data
opening file: C:/FG0981/FlightGear/data/Navaids/carrier_nav.dat
C:/FG0981/FlightGear/data/Navaids/TACAN_freq.dat
Error: RenderTexture requires the following unsupported OpenGL extensions:
WGL_ARB_extensions_stringAudio initialization failed!
instrument name: adf
... more instruments listed, ending with
instrument name: tacan
Reading xml electrical system model from C:/FG0981/FlightGear/data/Aircraft/Generic/generic-electrical.xml
Unknown exception in the main loop. Aborting...
Possible cause: No error

So I remove the disable of sound ... since I would like sound ... and increase the log level to 'info', it still ABORTS - after lots of console message, ending with -
...
Loading tile C:/FG0981/FlightGear/data/Scenery/Terrain/w130n30/w122n37/958456
token = OBJECT_BASE name = 958456.btg
token = OBJECT_SHARED name = Models/Structures/radio-medium.xml pos = -121.899,
37.8927 elevation = 964.9 heading = 0
Loading tile C:/FG0981/FlightGear/data/Scenery/Objects/w130n30/w122n37/958456
Unknown exception in the main loop. Aborting...
Possible cause: No error
Deleting a sample

... this is repeated 4 more times, then ABORT to console prompt ...

So I bump the log level to debug - in system.fgfsrc -
--log-level=debug
This massively increase the console output, but it STILL ABORTS. The last messages are -
...
Running Main Loop
======= ==== ====
Updating time
Current Unix calendar time = 1129492392 warp = 7080
Current GMT = 10/16/2005 19:53:12
Current Unix calendar time = 1129492392 warp = 7080
Current GMT = 10/16/2005 19:53:12
Current Julian Date = 2.45366e+006
COURSE: GMT = 9/16/105 19:53:12
March 21 noon (GMT) = 1111402800
Time since 3/21/105 GMT = 209.37
days = 209 hours = 19.8867 lon = 0 lst = 21.82
COURSE: GMT = 9/16/105 19:53:12
March 21 noon (GMT) = 1111402800
Time since 3/21/105 GMT = 209.37
days = 209 hours = 19.8867 lon = 122.357 lst = 13.6629
Current lon=0.00 Sidereal Time = 21.5765
gst => 165.582
Current LOCAL Sidereal Time = 13.4193 (13.4248) (diff = -0.243533)
Elapsed time interval is = 109000, previous remainder is = 5360
--> Frame rate is = 8
Model iterations needed = 13, new remainder = 6027
Updating adjusted fog parameters.
skip tacan
FGTileMgr::update()
State == Running
Unknown exception in the main loop. Aborting...
Possible cause: No error
Deleting a sample ... repeated 4 more times ...

It seems I MUST do BOTH ... Disable sound, and have log level of debug - NOW THAT FAILS ALSO ... Then why, and how did I get it FLYING before??? I am SURE this is the same system.fgfsrc I had before when it ran ok ... try again ... removing ALL the 'comment' lines, this is my system-fgfsrc, it shows -
--timeofday=noon
--altitude=10000
--aircraft=ufo
--fdm=ufo
--prop:/sim/hud/draw-fps=true
--log-level=debug
--enable-hud
--visibility=200000
--control=joystick
--disable-random-objects
--disable-panel
--disable-ai-models
--disable-clouds
--disable-skyblend
--fog-disable
--disable-sound

NOPE, another ABORT! Now I can NOT get it running, at all???

I reduce the system.fgfsrc to a miniscule -
--timeofday=noon
--log-level=debug
and it RUNS ... when I increase the throttle, I can take off ... across the grass, and second runway to the left ... I get into the air, but the control input is too slow, and I end up nose diving into the earth ... BUT IT RAN! NO ABORT! What is happening here???

So I add back a few of my 'preferences' into system.fgfsrc, as follows -
--timeofday=noon
--log-level=debug
--altitude=10000
--aircraft=ufo
--fdm=ufo
and FlightGear flies! Here is a snapshot, after doing a 'h' key-in, to enable the HUD, and a 'v' key-in to take the position of the 'spotter plane' ... just over the Bay bridge, with downtown SF on the left, the Golden Gate, just visible in the distant 'fog', and you can see my UFO model, and in the right foreground, random 'tree' objects ... ;=)) -

Ok, I add back another bunch of preferences ... I am just TOO LAZY to do them one-at-a-time ;=))
--prop:/sim/hud/draw-fps=true
--enable-hud
--visibility=200000
--control=joystick
--disable-random-objects
--disable-panel
--disable-ai-models
--disable-clouds
--disable-skyblend
--fog-disable
--disable-sound
save, and try again ...

And it ABORTS. Ok, I MUST try a few at a time ... just the first 4, removing all the 'disables' ... and it FLIES ...

This is a unique perspective of the Golden Gate model ... almost resting on the roof of the building at the southern end ... probably ONLY possible using the UFO, which can 'hover' ...

So the ABORT appears to be related to one of the 'disable' features ... I put back the first -
--disable-random-objects
and it flies ... add back one more ...
--disable-clouds
and FlightGear flies ...

Moving around in the UFO, you can get a unique perspective as to how FlightGear does its scenery ... The following image is taken while 'hovering' over the 'boundary' between the last existing download and installed scenery tile, and the 'sea' FlightGear 'generates' when it has no scenery to load ... of course this should be fixed if more scenery is download and installed ... or the auto-scenery loader enabled, that I have not tried ... but meantime ;=((

The white line is no-mans-land ;=)) To the left is the 'real' sea, and to the right is 'generated' sea ... but, unfortunately there is a GAP in between ... note the AGL HUD reading is showing 20 million, plus!!! I can only assume this is the distance to the centre of the earth ;=)) a kinda deep hole. The console output is quite clear about the situation -
...
Elapsed time interval is = 219000, previous remainder is = 6354
Model iterations needed = 27, new remainder = 354
prepare_ground_cache(): ac radius = 10, # triangles = 5, # wires = 0, # catapults = 0, ground_radius = 0
prepare_ground_cache(): trying to build cache without any scenery below the aircraft
...
FGTileMgr::update()
State == Running
DOING FULL TERRAIN INTERSECTION
no terrain intersection
...

I have read quite a number of posts on the development board, discussing these HOLES in the earth ;=)) Any sort of AI flying code, and auto-pilot code, gets REALLY CONFUSED when this happens ... It seems there are some such holes between some tiles, even when the scenery exists ... This is a special case only ... flying out of the existing scenery ... to show a hole ... perhaps the tile loading, scenery rendering code could be 'patched' to build a 'bridge' over this 'deeply' troubled water ;=))

This reminds me that I like to make an 'unsanctified' change here ... If the actual tile scenery does not exist, I think the simulator should indicate this, and not just paint water ... It starts in FlightGear, tileentry.cxx, around line 912 -
if ( !found_tile_base ) {
// no tile base found, generate an ocean tile on the fly for
// this area
ssgBranch *geometry = new ssgBranch;
Point3D c;
double br;
if ( sgGenTile( path_list[0], tile_bucket, &c, &br,
globals->get_matlib(), geometry ) )
{
center = c;
bounding_radius = br;
new_tile -> addKid( geometry );

And, of course, the function sgGenTile(...) is found in SimGear, obj.cxx, around line 57 -
// Generate an ocean tile
bool sgGenTile( const string& path, SGBucket b, Point3D *center, double *bounding_radius,
SGMaterialLib *matlib, ssgBranch* geometry )
{
ssgSimpleState *state = NULL;
geometry->setName( (char *)path.c_str() );
double tex_width = 1000.0;
// double tex_height;
// find Ocean material in the properties list
SGMaterial *mat = matlib->find( "Ocean" );
if ( mat != NULL ) {

To change the 'material' used, consult FlightGear/data/materials.xml ... look in the folder FlightGear/data/Textures/Terrain with a graphic viewer to find something ... I like the unknown.rgb - red-and-white-chequered pattern - which is listed with the name 'Unknown' in materials.xml ... change to -
 SGMaterial *mat = matlib->find( "Unknown" ); // personal pref only - grm
and recompile, link SimGear, the re-link FlightGear ...

I lot of people will probably not like this choice ... FlightGear has used this - generate water when no scenery tiles - to save generating Ocean scenery tiles, which, after all, is 4/5 of the world ... so when ever you are near an ocean border, you will probably see 'pink' in the not too far out to sea view ... The following is over the same HOLE, which shows the BIG DIFFERENCE ;=()

As the AGL HUD indicator shows, I am hovering over the HOLE again ... you can not see the white-ray so well from this 2,200 foot view, but you can see some of the vast ocean of red ;=)) It certainly destroys some of the realistic scenery illusion of the simulator, but serves as a reminder that I should download, and install some more scenery if I want to view the terrain in this area ...

But back to chasing my ABORT ... still to add the following 'disables' -
--disable-panel
--disable-ai-models
--disable-skyblend
--fog-disable
--disable-sound
but out of puff this night ;=))

back

CVS Update

Back the next day, with increased vigour, October 17 ;=)) I do a full CVS update, and compare SimGear/source and FlightGear/source with my work folder, hoping to find a fix to my AIFlightPlan.cxx/hxx null hack to get FlightGear linked ... but no such luck, yet ... at some point perhaps I should put a message on the development board ...

There have been 7 updates to SimGear ... and now I must be careful of my own update to obj.cxx ... I review these changes, and copy them from the CVS to my build folder ... after first saving - zipping up - the current list -
source\simgear\nasal\gc.c
source\simgear\props\props.cxx
source\simgear\props\props.hxx
souce\simgear\scene\model\shadanim.cxx
source\simgear\screen\shader.cpp
source\simgear\screen\texture.cxx
source\simgear\screen\texture.hxx

I add -
source\simgear\scene\tgdb\obj.cxx
the file I modified, for good measure ... and just to be SURE, I always to a FULL BATCH RE-BUILD, which includes a CLEAN first ... you never know how far reaching the changes will be, especially with header file ... Of course MSVC7 keeps good track of the dependencies, but in this case I am updating using a newer CVS file which may have a date older than my last build date, so I can not depend on MSVC7 knowing what to do ... so I do it ALL ... the batch re-build of Release and Debug takes less than 3 minutes ;=))

The compare of FlightGear produces a bigger list of changes -
Newer files -
source\docs-mini\README.multiplayer
source\src\AIModel\AIBase.cxx
source\src\AIModel\AIBase.hxx
source\src\AIModel\AIManager.cxx
source\src\AIModel\AIManager.hxx
source\src\ATC\AIEntity.cxx
source\src\ATC\AIMgr.cxx
source\src\Cockpit\hud_rwy.cxx
source\src\FDM\Balloon\BalloonSim.cpp
source\src\FDM\YASim\FGFDM.cpp
source\src\FDM\YASim\YASim.cxx
source\src\GUI\new_gui.cxx
source\src\GUI\new_gui.hxx
source\src\Instrumentation\od_gauge.cxx
source\src\Instrumentation\wxradar.cxx
source\src\Instrumentation\wxradar.hxx
source\src\Scenery\hitlist.cxx
source\src\Scenery\scenery.cxx
source\src\Scenery\tileentry.cxx
source\src\Systems\vacuum.cxx
source\src\Systems\vacuum.hxx
source\src\Traffic\Schedule.cxx
source\src\Traffic\Schedule.hxx
source\src\Traffic\TrafficMgr.cxx
source\src\Traffic\TrafficMgr.hxx
Older files ...
source\src\AIModel\AIFlightPlan.hxx
source\src\Instrumentation\tacan.cxx

The last two (2) are due to local changes I made, and I must carefully review these, to see if the original source has also be updated compared to mine ... regrettably, no CVS fix yet ... then I save (zip) the set ... do the update ... then the full re-build ...

I am rewarded with, some 16 minutes later, about 8 minutes each, for Debug and Release, with -
Rebuild All: 2 succeeded, 0 failed, 0 skipped
and no new problems ... as mentioned I am presently ignoring all the warning ... some of which could be the cause of this ABORT, but I hope not -
FlightGear - 0 error(s), 221 warning(s)
in each, Debug and Release ... in some 440 files compiled each time ...

This 16 minute re-build might seem long for some, on my current Intel P4 3.0GHZ, in Windows XP SP2, and I remember my first build of a large program, back in the early 80's ... it was all assembler, using MASM ... this took some 6 to 7 HOURS ... we used to schedule it overnight ... on an Intel 8086 at 4.77MHZ ... how times have changed ;=))

Now to run it ... it flies fine ... but I am getting annoyed that the throttle is always about half open when the flash fades out, and the scene appears ... as previously mentioned, this happens even though my throttle slider in the joystick is at zero ... it will return to zero if I do a quick blip up and back to zero ... my idea is that the joystick memory is not zeroed, when it is initialised ... I decide to digress, and chase this down ... for that, I will run the Debug version, under MSVC7 control ...

There is some 'interesting' code in main.cxx, about line 339 -
#if defined( ENABLE_PLIB_JOYSTICK )
// Read joystick and update control settings
// if ( fgGetString("/sim/control-mode") == "joystick" )
// {
// fgJoystickRead();
// }
#endif
BUT is has all been commented out! Why? ENABLE_PLIB_JOYSTICK has been defined in the build??? I try uncomment the block only to find that the function fgJoystickRead(); does not exist! That is a good enough reason to comment it out. Then why is it there at all?

Finding exactly WHERE FlightGear initialises the joystick is NOT EASY ... The main() of the console application is in bootstrap.cxx, which calls fgMainInit(argc, argv);, which is in main.cxx ... the GLUT call-back service, which is passed, is fgIdleFunction(), which increments a idle_state variable, and takes various action on each call-back ... but where is the joystick created? Maybe try to put a trap in the PLIB joystick library?

Ok, trapped at os_specific_s::getOEMProductName(...) in PLIB, jsWindows.cxx ... right after -
Initializing joystick binding
...

in the console ... now to trace it back to FlightGear ... back to FGInput::_init_joystick () ... and this where it is initialised, in input.cxx, in Lib_input, which is probably where it should be ;=)) -
void FGInput::init () {
_init_keyboard();
_init_joystick();
and the console output, shows the action -
Looking for bindings for joystick "SideWinder Joystick"
No config found for joystick "SideWinder Joystick"
Using default: "C:/FG0981/FlightGear/data/Input/Joysticks/Default/joystick.xml"

This happens in idle_state = 7. But what are the values, especially of the throttle slider? There is a read done, and it appears the value returned on some axis, [2], [1], [0] is 7FFFh ... WHY? Shouldn't this be zero? ... trapping at rawread(...) in js.cxx just happens too frequently to follow it exactly ... This joystick read is done in FGInput::_update_joystick (double dt) ... the actual 'read' is done in jsWindows.cxx, at void jsJoystick::rawRead ( int *buttons, float *axes ), and uses a Windows system call -
MMRESULT status = joyGetPosEx ( os->js_id, &(os->js) ) ;

It seems the ONLY way to fully debug this would be to ADD some diagnostic code ... output the values each time to say a file ... and review it later ... and I may have to compile and run the joystick sample code ... this is getting too hard for now, but have some sense now where it all happens, so will return to this story someday ...

Meantime, back to tracking down this ABORT ... using the Release version ... I remove the log level change, and use the default, just to ensure this has nothing to do with this ABORT. AND it seems it doesn't ;=))

As part of the ongoing improvement I had downloaded some European scenery ... I used the graphical interface at http://flightgear.org/Downloads/scenery-0.9.8.html , and selected the 10X10 degree block, e000n40, which downloads e000n40.gtz, 113MB, which is a change ... I seem to remember them as tar.gz files ... but the gtz suffix is good, in that it is supported by my WinZIP application ... so I unpacked it into C:/FG0981/FlightGear/data/scenery/terrain ... and added the following into system.fgfsrc -
airport=LFPO
since I live near Orly ;=)) ... and start FlightGear ...

Wow is me! Another ABORT!! It exits with the final console messages -
Adding subsystem gui
fgtzfile_read(): : Invalid argument
Timezone reading failed

What can be wrong here?

Switch back into MSVC7 to run the Debug version, and set a trap in lowleveltime.cxx, in SimGear, which is where this message comes from ... the debug configuration take an age to load the airport file, apt.dat.gz, so you must be very patient! ... at the debug trap, it becomes immediately obvious what the problem is ... the file name passed looks ok, except it has an additional 0x0d at the end ... maybe *nix systems accept a path/filename ending in an 0x0d, or the clean file name is passed in those systems ...

Using the memory window, I zero this character ... and the file C:/FG0981/FlightGear/data/Timezone/Europe/Paris is opened, and successfully read ... but I continue tracing to find out who passed this errant name ... it falls back to -
static void fgtzset_internal (int always, const char *tz)
then
struct tm * fgtz_convert (const time_t *timer, int use_localtime, struct tm *tp, const char *tzName)
and
struct tm * fgLocaltime (const time_t *t, const char *tzName)
but eventually back to fg_init.cxx, in FlightGear, with the call -
time_t aircraftLocalTime =
sgTimeGetGMT( fgLocaltime(&cur_time, t->get_zonename() ) );

where the SGTime * t was obtained a few lines up by -
SGTime *t = globals->get_time_params();
in
void fgInitTimeOffset() {
so must go back further ... when and where did the global get_time_params() gets set up, and why is the function t->get_zonename() returning a string with an 0x0d appended?

The fgInitTimeOffset() is called as part of -
bool fgInitSubsystems() {
which, in turn is part of the idle_state == 7, in the GLUT call-back, fgIdleFunction() ... I note, looking back up the big list of actions here, that when idle_state == 4, the following actions are taken -
SGTime *t = fgInitTime();
globals->set_time_params( t );

Maybe this is where it happens ... I set debug traps, for next time, and let it run for now ...

But quickly find myself back in lowleveltime.cxx, at my trap in fgtzfile_read() ... this is called a SECOND TIME? But at least I can see it is pointing to the SAME memory, where I fixed the file name, so this time it opens the file ok ... but from where is it called a second time?

Tracing it back, it is called by a direct fgInitTimeOffset() call with idle_state == 8 ... this appears a duplicate, and perhaps unnecessary, since it is already called as part of fgInitSubsystems ... probably should post this to the development board, but I only like doing a post, when I have a SOLUTION ... not just a complaint ;=))

As usually, the scenery fades in with my UFO racing along at a few thousand clicks ... I have to blip the throttle to stop it ... looking back at Orly, it looks different to last time I was here ... now the runways are sort of painted without an airport boundary ... I try to get a screen snap, but POOF, FlightGear ABORTS again ...

Double wow is me! ... FlightGear certainly appear more 'unstable' than it used to be ...

Out of puff again today ... well not exactly ... just that other duties call ...

back

Tuesday, 18 October, 2005 - Back with renewed vigour ;=)) I reload MSVC7 ... thankfully it always remembers all the debug traps set, and files open, etc ...

Ok, the function fgInitTime() calls -
SGTimeZoneContainer::SGTimeZoneContainer(const char *filename)
Well, not exactly calls it, but does a 'new', which calls this constructor with the file name C:/FG0981/FlightGear/data/Timezone/zone.tab, and this file is processed, line by line ... skipping lines beginning with a '#' character ... I NOTE each lines ends in an 0x0d, 0x0a ... standard windows line ending ... this always gives problems to unix programmers, who only expect '\n' to terminate a line ;=()

Sure enough, in the constructor, in timezone.cxx, at C:/FG0981/SimGear/source/simgear/timing -
SGTimeZone::SGTimeZone(const char *infoString) : SGGeoCoord() {
the line is processed, and the following logic, does it best -
 start = i;
while (!((infoString[i] == '\t') || (infoString[i] == '\n'))) {
i++;
}
size = i - start;
strncpy(buffer, (&infoString[start]), size);
buffer[size] = 0;
descriptor = buffer;
Since, in windows, sometimes translated during the FTP transfer of the file, the line will end in '\r\n', and the '\r' will be left ... to be TRULY CROSS-PLATFORM CODE ... the while(...) line, line 104, needs to be changed to -
while (!((infoString[i] == '\t') || (infoString[i] == '\n') || (infoString[i] == '\r'))) {

This would also then work on a MAC, which I understand can use just '\r' to terminate a line ... Must remember to post this to the development board, in the hope the change will get into SimGear CVS sometime ;=))

I load up the SimGear.sln, into another copy of MSVC7 ... make the change to the line, compile, and link - build ... Then back to MSVC7 containing FlightGear, and an F7 causes a link with the new SimGear libraries, debug, and release ...

Now, my FlightGear flies ... it loads, but while climbing to altitude to get a screen shot of this 'new' Orly ... I get the other ABORT again ... the last few things in the debug level console output, are no help at all -
Updating light parameters.
Sun angle = 58.4121
ambient = 0.2 diffuse = 0.995635 specular = 0.5 sky = 0.99027
interpolate(): lookup error, x to big = 31030
interpolate(): lookup error, x to big = 31030
skip tacan
FGTileMgr::update()
State == Running
Loading tile C:/FG0981/FlightGear/data/Scenery/Terrain/e000n40/e001n48/2974337
token = OBJECT_BASE name = 2974337.btg
Unknown exception in the main loop. Aborting...
Possible cause: No error
Deleting a sample ... written another 4 times!

BAH!

I start the sim at 30,000 feet, so I can get this screen shot before the ABORT -


Paris, Orly, from 30,000 feet ..

I live nearby in Antony ... so KNOW there is farm land around, but the last time I looked, there were no patch-work farm field between the runways ;=)) Also, must one day check if the Orly VAL, a 11-minute, driverless train from the Antony RER station, to Orly airport is in any database used to build this scenery ...

This is Google earth, from about the same altitude and perspective - Thank you Google for these great images -

 

The brown pin, in the top right of the Google image is where I live ... ;=)) As can be seen, between the two main runways is just all buildings ... not farm land ... otherwise there is just brown dirt, out to the perimeter fence that I know is there ... Why does FlightGear split it into two simple runway sets? 

Now that the timezone untimely program exit is fixed, I am starting to wonder if these two ABORTS are related? Maybe there is an event, which only runs after a certain amount of time, which is causing this all ... and not due at all to anything I put in the system.fgfsrc file ...

Anyway, again running out of time today, and I do want to get something posted on the development board, so I turn to that for now ...

back

Wednesday, 19 October, 2005

As usual, first I do my cvs update, and compare ... although I update ALL folders in my FGCVS folder, I am mainly only concerned about SimGear and FlightGear, at least initially ....
(a) There have been no changes in SimGear. Of course, now I must carefully check that the two (2) files I have altered, obj.cxx (change to 'Unknown', instead of 'Ocean), and timezone.cxx (fix to work with windows line endings in zone.tab file), have not had other changes ...
(b) There are 9 differences shown in my compare tool ... 1 new file ...
 docs-mini\README.mingw
6 are newer ...
source\src\AIModel\AIBase.cxx
source\src\AIModel\AIFlightPlan.hxx
source\src\AIModel\AIFlightPlanCreate.cxx
source\src\Airports\simple.cxx
source\src\Airports\simple.hxx
source\src\Traffic\Schedule.cxx
and 2 are older ...
source\src\Instrumentation\tacan.cxx
source\src\Main\main.cxx

I look at all the changes ... note some changes in AI, new classes in Airports, etc ... the tacan.cxx is my change (and to &&), and main.cxx has no changes at all ... this is just a case where I tried changing something in main.cxx, but eventually put at back the way it was ... I will copy all except the tacan.cxx, after I save (zip) these files, to be available for an undo ;=)) oops, missed this step ;=(( oh, well ... then do the 15 minute, or so, re-build of debug and release configurations ...

Thankfully there are no new fatal errors, especially since I messed up my zip save ;=/ but I am reminded that there are some 247 warnings issued for each configuration ... for those with the energy, here is the complete build log, of the release version, written by MSVC7 ... which lists them all, and more ;=))

Ever hopeful that this update has got rid of my ABORTS, I fire up my new FlightGear.exe ... but ALAS, it aborts after just a few minutes after the Flash screen is removed, with no new information ... ;=(( the ONLY action I did, was to blip the throttle, to get it back to zero ...

Looking further into this throttle thing ... reading controls.cxx I note the constructor does a throttle_idle( true ) ... does this set the throttle non-zero? ... in the FGControls::reset_all() function, there is a specific set_throttle( ALL_ENGINES, 0.0 );, but NOT in the constructor, and a throttle_idle = true; ...

Bah! I try a crude hack ... add the following into the init() function -
globals->get_controls()->set_throttle( FGControls::ALL_ENGINES, 0.0 );
and see if my UFO starts at zero speed ...

Hey, it seems MSVC7 no longer keeps good track of dependencies ??? I also added an int done_one; variable to the class, but ONLY ufo.cxx was re-compiled ... but, it is also included in fg_init.cxx ... what is going on here? Do I have to force a full re-build EVERY TIME? Meantime, I manually delete fg_init.obj - release and debug - and re-compile ...

And that appears to have done the trick ... the UFO is stationary ... phew ... but still after a few minutes, now I have done nothing, FlightGear ABORTS ... yuk!

Off today to buy a new PC for a young friend and his Mum ... 

back

Thursday, October 20, 2005.

We eventually, after a bit of searching around ... chose a Compaq, AMD powered, with HP 17" flat screen, for 800 Euro TTC, from a Conforama store!

Getting frustrated with my lack of progress, on this ABORT, I decided to post a message, on the development board, and all is SOLVED, sort of, quite quickly. The message I posted -

Subject: 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

Thankfully I got a quick reply, shortened here, a little -

Message: 6
Date: Thu, 20 Oct 2005 18:43:42 +0200
From: Harald JOHNSEN <hjohnsen@evc.net>
Subject: Re: [Flightgear-devel] Two problems - 1 easy and 1 hard! - in XP using MSVC7

> 1. The Easy fix

I just tried : I did delete the file zone.tab then made a checkout.
The checkout gives me a 'text' file with msdos line endings. I don't understant why.
The zone.tab from the 0.9.8 package from F.B. contains the file with a unix line-ending.

> 2. The Hard find

There is no startup abort for xp with the one week ago cvs.
You should trap the exceptions (set that in the debug menu) to find the line
that throw the exception.

Harald.

Adding a trap, and return to debugger, in the debug menu, I was able to quickly SEE what the problems was - a simple OUT-OF-MEMORY - I removed the unrealistic 100000 metres visibility item, and voila, I was able to post a result on the board -

Thursday, 20 October 2005.

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=200000.00000000000) 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,
200000 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 200000 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

I must remind myself to watch for this in future, and maybe at some time experiment with INCREASING the virtual memory, through the swap file parameters ...

End of this ABORT SAGA ... It was nothing to do with the application ... just a FAILED MEMORY ALLOCATION ... Bah! Why didn't I think of this?

back