Melchior FRANZ <[EMAIL PROTECTED]> said: > Now with a different 'approach'. Starting on ground ... > > $ fgfs --lon=-122.4998 --lat=37.5845 --heading=275 > > ... and very slowly taxiing over the border. Right when I pass over > I get thrown on my back. Ouch ... :-| >
That did it. There is definately something at this location, on my display driven by V3-3000 I see a white line (right side of picture): http://www.spiderbark.com/fgfs/SanAndreas.png The AGL glitch you see basically means that there's a hole down there that goes to nowhere, an actual gap between tiles. AGL is determined by intersecting scenery tiles under the aircraft and measuring the distance from the aircraft position. If you cross a gap in the scenery then you'll get those kinds of numbers. On my system the c310 will ride over it (like thumping over a pothole) and the c172 will just drop in there and act "crashed". Probably if I hit it at the right angle or speed the c310 would do the same. With a narrow fissure like this (I think) it's possible for the AGL to be momentarily screwed up, the aircraft then "drops" and a wing tip or nose "contact" with tile on either side of the gap triggers crash detection. I'm not familiar with the scenery generation, so I can't tell you why the gap is here. When I was working on getting the agl calculation functioning with all the viewer changes, I toyed with the idea doing something that ignored sudden (and/or unreasonable) variations to AGL, at least for a few frames. It was mostly in response to what happens when a very fast aircraft outruns the tile loading, which I decided wasn't a big enough problem to warrant tracking AGL variations. Best, Jim _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
