As noted by John in February, but I did not see it addressed in this thread, is
the chase view issue in 2.0. (chase view does not follow heading, and if you
select chase while in a turn the viewpoint holds that angle until you leave the
viewpoint) I sincerely hope it's not a feature, as there
On Mon, 15 Mar 2010, Peter Brown wrote:
As noted by John in February, but I did not see it addressed in this
thread, is the chase view issue in 2.0. (chase view does not follow
heading, and if you select chase while in a turn the viewpoint holds
that angle until you leave the viewpoint)
Is it the same as this bug
Chase-view broken
http://code.google.com/p/flightgear-bugs/issues/detail?id=99
pete
Anders Gidenstam wrote:
On Mon, 15 Mar 2010, Peter Brown wrote:
As noted by John in February, but I did not see it addressed in this
thread, is the chase view issue in 2.0.
On Mon, 15 Mar 2010, Pete Morgan wrote:
Is it the same as this bug
Chase-view broken
http://code.google.com/p/flightgear-bugs/issues/detail?id=99
Yes, it seems so.
Cheers,
Anders
--
---
Anders Gidenstam
WWW:
On Tue, Feb 9, 2010 at 1:37 PM, John Denker wrote:
Has anybody used the --generic record/playback feature recently?
The same trouble was discussed at 2008 :
http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16539.html
and
John Denker wrote:
On 02/09/2010 01:14 PM, Curtis Olson wrote:
lon/lat are being written out as a float. This should be switched to
double. The format specifier is %f but it might be better to specify a
fixed number of decimal places appropriate for the required visual
precision. I don't
Has anybody used the --generic record/playback feature
recently?
It seems to have some very noticeable bugs:
When using the --generic record/playback feature, I
observe numerous view-related problems:
* Helicopter view: the size of the aircraft throbs
at a high rate, getting bigger and
Hi John,
The first thought that comes to mind is to double check the precision
(significant digits) of the data you are writing out. If you are writing
out heading for instance with 0 or 1 decimal digits or position with 4
decimal digits, that could account for this sort of thing.
Regards,
On 02/09/2010 12:43 PM, Curtis Olson wrote:
The first thought that comes to mind is to double check the precision
(significant digits) of the data you are writing out. If you are writing
out heading for instance with 0 or 1 decimal digits or position with 4
decimal digits, that could account
Right, I wouldn't consider playback.xml to be the most well conceived
generic protocol configuration file, but it serves as an interesting example
and starting point at least.
lon/lat are being written out as a float. This should be switched to
double. The format specifier is %f but it might be
On Feb 9, 2010, at 3:14 PM, Curtis Olson wrote:
Notice you are only getting 6 decimal places on your lat/lon and I
know from a past life that this will probably resolve down to a
resolution of maybe 10-20 meters.
Hmm
6 decimal places should get you sub meter precision
On Tue, Feb 9, 2010 at 2:28 PM, Norman Vine wrote:
On Feb 9, 2010, at 3:14 PM, Curtis Olson wrote:
Notice you are only getting 6 decimal places on your lat/lon and I know
from a past life that this will probably resolve down to a resolution of
maybe 10-20 meters.
Hmm
6 decimal places
A while back I was trying to read in lat/long and found a lot of jitter.
I finally found that FG generic was actually only able to read in floats. At
that time I found that the designation in the format was just being used for
output of variables. But for input they were being put into the
On 02/09/2010 01:14 PM, Curtis Olson wrote:
lon/lat are being written out as a float. This should be switched to
double. The format specifier is %f but it might be better to specify a
fixed number of decimal places appropriate for the required visual
precision. I don't have my calculator
On 02/09/2010 01:14 PM, Curtis Olson wrote:
Right, I wouldn't consider playback.xml to be the most well conceived
generic protocol configuration file, ...
Is there some other protocol file that should be
used instead?
None of the other Protocol/*.xml files seem
particularly suited to the
I've only started using the generic protocol stuff very recently. I think
there have been some recent (v2.0) patches to fix some of these issues we've
been discussing. Originally there was some missing double support, etc.
Personally I've never tried the record/playback stuff this using the
16 matches
Mail list logo
