On Dienstag 03 Mai 2005 14:17, Melchior FRANZ wrote:
Try adding --log-level=info for a possible hint,
./fgfs --lat=87 --long=28 --altitude=3 --log-level=info
That's an old, well known bug. If you position fgfs exactly on the tile
boundaries (*integer* lon/lat), the intersection code
* Mathias Fröhlich -- Thursday 26 May 2005 12:01:
On Dienstag 03 Mai 2005 14:17, Melchior FRANZ wrote:
Try adding --log-level=info for a possible hint,
./fgfs --lat=87 --long=28 --altitude=3 --log-level=info
That's an old, well known bug. If you position fgfs exactly on the tile
On Donnerstag 26 Mai 2005 12:21, Melchior FRANZ wrote:
Unfortunately, a similar bug showed up recently for *bucket* boundaries.
If you set /position/{latitude,longitude}-deg to a bucket boundary, fgfs
refuses to set /position/elevation-m accordingly. It simply lets the old
elevation in the
* Mathias Fröhlich -- Thursday 26 May 2005 12:29:
On Donnerstag 26 Mai 2005 12:21, Melchior FRANZ wrote:
Unfortunately, a similar bug showed up recently for *bucket* boundaries.
If you set /position/{latitude,longitude}-deg to a bucket boundary, fgfs
refuses to set /position/elevation-m
On Donnerstag 26 Mai 2005 12:37, Melchior FRANZ wrote:
Hey! I update compile in the same minute a new cvs-log commit message
comes in if I'm at my computer. Yes, this happens with CVS/HEAD as of *now*
(Thu May 26 12:36:12 CEST 2005). I had tried it as soon as I saw the fix
because I had
Hi,
On Donnerstag 26 Mai 2005 15:10, Melchior FRANZ wrote:
BTW: the scenery doesn't show anything unusual and suspicious. Not even the
familiar crack line. And starting fgfs with --lon=16.5 --lat=48.5833 works
flawlessly.
Hmm, that did not for me ...
But with the attached patch it did, at
* Mathias Fröhlich -- Thursday 26 May 2005 15:50:
On Donnerstag 26 Mai 2005 15:10, Melchior FRANZ wrote:
BTW: the scenery doesn't show anything unusual and suspicious. Not even the
familiar crack line. And starting fgfs with --lon=16.5 --lat=48.5833 works
flawlessly.
Hmm, that did not for
* Paul Furber -- Tuesday 03 May 2005 12:50:
I compiled the CVS versions of SimGear and FlightGear last night and
they were roughly 40% faster than 0.9.8 - which is very impressive. ]
Very strange. I'm not aware of any performance improvements since 0.9.8.
(While there were a few very effective
On Tue, 2005-05-03 at 13:26 +0200, Melchior FRANZ wrote:
* Paul Furber -- Tuesday 03 May 2005 12:50:
it's just the Himalayas region which doesn't work. (doesn't work on 0.9.8
either) I'm running CVS versions from last night on amd64 Gentoo Linux.
Any ideas?
No. If you had posted a
Quoting Paul Furber:
On Tue, 2005-05-03 at 13:26 +0200, Melchior FRANZ wrote:
* Paul Furber -- Tuesday 03 May 2005 12:50:
it's just the Himalayas region which doesn't work. (doesn't work on 0.9.8
either) I'm running CVS versions from last night on amd64 Gentoo Linux.
Any ideas?
* Paul Furber -- Tuesday 03 May 2005 14:07:
On Tue, 2005-05-03 at 13:26 +0200, Melchior FRANZ wrote:
No. If you had posted a command line that exposes the problem, *hundreds*
of fgfs developers would have tried to reproduce it, and maybe would have
been able to reproduce it and to find a
* Frederic Bouvier -- Tuesday 03 May 2005 14:12:
Quoting Paul Furber:
./fgfs --lat=87 --long=28 --altitude=3 --log-level=info
Classical numerical problem at tile boundary. Try that instead :
./fgfs --lat=87.0001 --long=28.0001 --altitude=3
^
Hahaaa!
On Tue, 2005-05-03 at 14:17 +0200, Melchior FRANZ wrote:
That's an old, well known bug. If you position fgfs exactly on the tile
boundaries
(*integer* lon/lat), the intersection code somehow falls through between the
tiles. Try this:
$ ./fgfs --lat=87.001 --long=28.001 --altitude=3
13 matches
Mail list logo
