On 01/14/2009 12:43 PM, Csaba Halász wrote:
> If anybody knows a better value than 0, speak up. It will be slowly
> pulled to the proper value by the low-pass filter anyway.
Initializing it to zero is 100% fine. At this point in
the initialization process, no better value is available.
Actually
Laser gyros do indeed behave the way that the wiki page describes.
Mechanical gyros, such as you find in light aircraft, have other drift
sources that are considerably larger than the diurnal one. And, since
the aircraft tend not to move far from their home latitude, there is
an attempt by mechani
hi, doing some nav with the pa24-250, i found the gyro compas drift was
always -15°/hour.
I never went in a real aircraft except as passenger, but if i refer to
this page:
http://en.wikipedia.org/wiki/Heading_indicator
Shouldn't drift be related to the sin(lat), and opposite sign in the
sou
Csaba Halász wrote:
> On 32 bit system, sizeof(T_PositionMsg) = 196. On 64 bit system it is
> 200, due to extra 4 bytes padding at the end.
>
> To make matters worse, in the assembled MP packet this message is
> followed by property values.
> Assuming the padding bytes are zero, a 32 bit receiver
On 32 bit system, sizeof(T_PositionMsg) = 196. On 64 bit system it is
200, due to extra 4 bytes padding at the end.
To make matters worse, in the assembled MP packet this message is
followed by property values.
Assuming the padding bytes are zero, a 32 bit receiver should be able
to process packet
gerard robin wrote:
> On jeudi 15 janvier 2009, James Turner wrote:
> > On 14 Jan 2009, at 23:56, gerard robin wrote:
> > > AND what about clouds with blue_edge ?
> > >
> > > http://pagesperso-orange.fr/GRTux/3DClouds-blue_edge.jpg
> >
> > I'd say, not worth delaying 1.9.1 for - unless there is a
James Turner wrote:
>On 14 Jan 2009, at 23:56, gerard robin wrote:
>>
>>AND what about clouds with blue_edge ?
>>
>>http://pagesperso-orange.fr/GRTux/3DClouds-blue_edge.jpg
>
> I'd say, not worth delaying 1.9.1 for - unless there is a low-risk fix, which
> I doubt,
> since it appears to be a sor
On jeudi 15 janvier 2009, James Turner wrote:
> On 14 Jan 2009, at 23:56, gerard robin wrote:
> > AND what about clouds with blue_edge ?
> >
> > http://pagesperso-orange.fr/GRTux/3DClouds-blue_edge.jpg
>
> I'd say, not worth delaying 1.9.1 for - unless there is a low-risk
> fix, which I doubt, sin
On 14 Jan 2009, at 23:56, gerard robin wrote:
AND what about clouds with blue_edge ?
http://pagesperso-orange.fr/GRTux/3DClouds-blue_edge.jpg
I'd say, not worth delaying 1.9.1 for - unless there is a low-risk
fix, which I doubt, since it appears to be a sorting issue. 'Clouds
look a bit
On Thu, Jan 15, 2009 at 12:56 AM, James Turner wrote:
>
> On 14 Jan 2009, at 23:40, Csaba Halász wrote:
>
>> There are some pending NaN problems I have reported, but have not
>> been fixed.
>> And users are complaining about IntersectionVisitor/CullVisitor
>> flooding console with messages about N
On 14 Jan 2009, at 23:40, Csaba Halász wrote:
> There are some pending NaN problems I have reported, but have not
> been fixed.
> And users are complaining about IntersectionVisitor/CullVisitor
> flooding console with messages about NaNs ;)
Between Fred, Tim and myself, I thought we'd committe
On jeudi 15 janvier 2009, Csaba Halász wrote:
> On Thu, Jan 15, 2009 at 12:31 AM, Tim Moore wrote:
> > There has been a flurry of bug fixes in the last few days. I want to
> > review the state of the maint branches in the simgear and flightgear git
> > repositories and suggest that they would now
On 14 Jan 2009, at 23:31, Tim Moore wrote:
> There has been a flurry of bug fixes in the last few days. I want to
> review the
> state of the maint branches in the simgear and flightgear git
> repositories and
> suggest that they would now be a good source for a 1.9.1 bug fix
> release. I'v
On Thu, Jan 15, 2009 at 12:31 AM, Tim Moore wrote:
> There has been a flurry of bug fixes in the last few days. I want to review
> the
> state of the maint branches in the simgear and flightgear git repositories and
> suggest that they would now be a good source for a 1.9.1 bug fix release. I've
There has been a flurry of bug fixes in the last few days. I want to review the
state of the maint branches in the simgear and flightgear git repositories and
suggest that they would now be a good source for a 1.9.1 bug fix release. I've
been fairly conservative and have been only checking fixes
I hope this doesn't break anything. ;)
--
Csaba/Jester
Index: src/Aircraft/controls.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Aircraft/controls.cxx,v
retrieving revision 1.5
diff -u -r1.5 controls.cxx
--- src/Aircraft/cont
syd adams wrote:
"I changed the neelde animation because it was pointed out that it was
too insensitive , but now it has a very narrow window to operate in ,
and the ealier discussions and the manual don't jive so I'll look
into it some more . The changes I made were about a week or so ago.
I
Stuart Buchanan wrote:
"When you close the Weather Scenario dialog, instead of interpolating to the
new weather values, the environment is rebuilt from scratch based on the
selected scenario. This may cause an immediate wind change (which the aircraft
has to react to) and/or cloud changes."
Ah
On 14 Jan 2009, at 20:13, syd adams wrote:
> This might be partly my fault , I changed the neelde animation
> because it was pointed out that it was too insensitive , but now it
> has a very narrow window to operate in , and the ealier discussions
> and the manual don't jive so I'll lo
On 14 Jan 2009, at 19:40, Martin Spott wrote:
> To my understanding of your posting you're implying that someone would
> like to move the shoreline around. Indeed, if we would derive the
> coastline entirely from the SRTM elevation, then we theoretically
> _might_ run into trouble, but nobody's t
Yikes! I *really* got the year wrong. That is of course the 2009-01-11 build.
And, apologies for not deleting out the (non-sequitor) e-mail I responded to.
Apologies, -R.
Robert M. Shearman, Jr.
Transit Operations Supervisor,
University of Maryland Department of Transportation
also known as
On Wed, Jan 14, 2009 at 7:13 AM, Rob Shearman, Jr. wrote:
> Hello all --
>
> Using 2208-01-11 CVS build flying the Cessna Citation Bravo on Windows
> Vista with NVIDIA 6100 GeForce 405...
>
> Lately I have noticed that the glideslopes seem to be uniformly wrong or
> inoperable somehow. This chang
Martin Spott wrote:
> BTW, the sort of bathymetry data I'm talking about has, per definition,
> always an 'elevation' at or below zero MSL, [...]
well, those areas that don't apply are called "islands" or at
least "littoral" :-)
Martin.
--
Unix _IS_ user friendly - it's just sele
If anybody knows a better value than 0, speak up. It will be slowly
pulled to the proper value by the low-pass filter anyway.
--
Csaba/Jester
Index: src/Instrumentation/altimeter.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/I
"Curtis Olson" wrote:
> On Wed, Jan 14, 2009 at 12:23 PM, Martin Spott wrote:
> > BUT, the story about merging vector data is still not right on topic.
> > Your response lacks an explanation why you consider it as being
> > impractical to blend the bathymetry data against the coastline in the
> >
* Stuart Buchanan -- Wednesday 14 January 2009:
> In v1.9.0, they are separated, so you must have the weather
> scenario set to METAR for real-weather-fetch to work and be
> updated by subsequent METAR updates.
Just for the record: METAR scenario is automatically chosen
by the --enable-real-weath
Rob Shearman, Jr. wrote:
>Also, this has possibly been going on quite some time now (since I started
>reporting NaN bugs on my medium-haul flights),
> but in many cases, the METAR doesn't change the active wind and cloud
> settings unless I actually look at the METAR
> (Environment --> Weather
On Wed, Jan 14, 2009 at 12:23 PM, Martin Spott wrote:
> I'm quite aware of these implications - this is what I've been pulling
> together into the "due to the corresponding landuse data"- phrase. It's
> not only about freshwater, basically this affects any sort of ground
> coverage that is meant t
"Curtis Olson" wrote:
> I still would like to find a way to move back to the GSHHS data set if we
> can figure out a way to resolve problems with combining that data set with
> VMAP0 freshwater data (which often conflicts with GSHHS ... things GSHHS
> considers freshwater might be considered outsi
James Turner wrote:
> Sadly I tend to agree with Curt - while it sounds easy to create nice
> shaders for water, it's not worth it if it puts SFO / London / Florida
> under water.
I agree with that we should not put major terrain areas under water, on
the other hand I don't see any justificat
On Wed, Jan 14, 2009 at 10:36 AM, Martin Spott wrote:
> Well, currently we're 'adjusting' the Terrain to a hypothetical
> shoreline in a very simple way: Everything that lies within the VMap0
> definition of political boundaries (our current coastline) is defined
> as ground and any SRTM point tha
On 14 Jan 2009, at 16:00, Curtis Olson wrote:
> My sense is that there are many areas in the world where the slope
> of the shore line is very shallow. Also don't forget that our SRTM
> data has a resolution / random noise element of about +/- 5 to 10
> meters. I think that these things c
"Curtis Olson" wrote:
> On Wed, Jan 14, 2009 at 9:35 AM, Martin Spott wrote:
> > Secondly, using bathymetry 'elevation' data we'd
> > certainly be able to create seabed 'Terrain' for "Ocean" and probably
> > also for "Lake" areas - probably not as detailed as
> > the regular surface but suffici
Martin, thank You for Your answers!
Right now I did a bit "unproper" hack, "pulling-out" water of the surface.
While reading of BTG file in SG I look for a material name, and
according to it give a osg::Node an identifier, in my case "Water" or
"Ground", Then, at FG side I use NodeVisitor pattern t
On Wed, Jan 14, 2009 at 9:35 AM, Martin Spott wrote:
> James Turner wrote:
>
> > I've idly wondered about pulling the water out of the generated
> > scenery, and instead creating 'ground' down to the low tide line. The
> > water surface could then be created at runtime, allowing for tides,
> > wav
James Turner wrote:
> I've idly wondered about pulling the water out of the generated
> scenery, and instead creating 'ground' down to the low tide line. The
> water surface could then be created at runtime, allowing for tides,
> waves, and other effects depending on the GPU/CPU power availa
On 14 Jan 2009, at 15:13, Rob Shearman, Jr. wrote:
Lately I have noticed that the glideslopes seem to be uniformly
wrong or inoperable somehow. This changed within the last couple of
builds. Previously, when on final, the visual glideslope indicators
would essentially match up with what
On Wed, Jan 14, 2009 at 4:13 PM, Rob Shearman, Jr. wrote:
> Hello all --
>
> Using 2208-01-11 CVS build flying the Cessna Citation Bravo on Windows Vista
> with NVIDIA 6100 GeForce 405...
Oh man, in 199 years we still haven't managed to fix this bug? :D
> Subject: [Flightgear-devel] [BUG] FGEnvi
Hello all --
Using 2208-01-11 CVS build flying the Cessna Citation Bravo on Windows Vista
with NVIDIA 6100 GeForce 405...
Lately I have noticed that the glideslopes seem to be uniformly wrong or
inoperable somehow. This changed within the last couple of builds.
Previously, when on final, the
On mercredi 14 janvier 2009, James Turner wrote:
> On 14 Jan 2009, at 11:16, Martin Spott wrote:
> >> As far as I know - there's no diference between solid and liquid
> >> surfaces
> >> from FG/SG point of view. In other words
> >> - rivers, lakes, ocean are a part of TerraGear scenery (except
> >>
On 14 Jan 2009, at 11:16, Martin Spott wrote:
>> As far as I know - there's no diference between solid and liquid
>> surfaces
>> from FG/SG point of view. In other words
>> - rivers, lakes, ocean are a part of TerraGear scenery (except
>> OceanTiles
>> for non existent BTG-s of course).
>
> R
Csaba Halász wrote:
> Problem: Apparently when you add an alias to a property node, the
> reference count of the target of the alias isn't incremented, so it
> can vanish at any moment.
> Fix: Since the SGPropertyNode class is hand managing its value
> pointers anyway, I don't see much point in usi
On 13 Jan 2009, at 17:41, Csaba Halász wrote:
> Somebody please commit this.
Done.
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Vladimir,
"Vladimir Karmisin" wrote:
> As far as I know - there's no diference between solid and liquid surfaces
> from FG/SG point of view. In other words
> - rivers, lakes, ocean are a part of TerraGear scenery (except OceanTiles
> for non existent BTG-s of course).
Right, in the current Terra
Csaba Halász wrote:
> The clouds_3d_enabled member is not initialized in the constructor,
> but the set_3dClouds function depends on it:
>
> void FGClouds::set_3dClouds(bool enable)
> {
> if (enable != clouds_3d_enabled) {
> clouds_3d_enabled = enable;
> buildCloudLayers();
>
Csaba Halász wrote:
> 540 // draw numbers
> 541 std::ostringstream str;
> 542 str << i;
> 543 const char *num = str.str().c_str();
>
> The str.str() is returning a temporary string, that gets immediately
> freed, taking the returned c
Csaba Halász wrote:
> Hi!
>
> The copy constructor in question:
>
> 145 FGEnvironment::FGEnvironment (const FGEnvironment &env)
> 146 {
> 147 FGEnvironment();
> 148 copy(env);
> 149 }
>
> I guess that wants to call the default constructor first. However,
> that doesn'
Tim Moore wrote:
> Csaba Halász wrote:
>> Hi!
>>
>> The copy constructor in question:
>>
>> 145 FGEnvironment::FGEnvironment (const FGEnvironment &env)
>> 146 {
>> 147 FGEnvironment();
>> 148 copy(env);
>> 149 }
>>
>> I guess that wants to call the default constructor fi
48 matches
Mail list logo