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 first. However,
that
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't work. See
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_str()
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();
}
}
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 Terrain
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
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 using
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).
Right, in 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
OceanTiles
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,
On Wed, Jan 14, 2009 at 4:13 PM, Rob Shearman, Jr. rmsj...@yahoo.com 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]
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
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
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,
waves, and
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 to get a
Curtis Olson wrote:
On Wed, Jan 14, 2009 at 9:35 AM, Martin Spott wrote:
Secondly, PROPER DESIGN using bathymetry 'elevation' data we'd
certainly be able to create seabed 'Terrain' for Ocean and probably
also for Lake areas /PROPER DESIGN - probably not as detailed as
the regular
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
On Wed, Jan 14, 2009 at 10:36 AM, Martin Spott martin.sp...@mgras.netwrote:
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
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
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 outside
On Wed, Jan 14, 2009 at 12:23 PM, Martin Spott martin.sp...@mgras.netwrote:
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
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
* 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
Curtis Olson wrote:
On Wed, Jan 14, 2009 at 12:23 PM, Martin Spott martin.sp...@mgras.netwrote:
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
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:
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 selective
On Wed, Jan 14, 2009 at 7:13 AM, Rob Shearman, Jr. rmsj...@yahoo.comwrote:
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.
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
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
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 look
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
---
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
On Thu, Jan 15, 2009 at 12:31 AM, Tim Moore timo...@redhat.com 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
On jeudi 15 janvier 2009, Csaba Halász wrote:
On Thu, Jan 15, 2009 at 12:31 AM, Tim Moore timo...@redhat.com 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
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've
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 committed
On Thu, Jan 15, 2009 at 12:56 AM, James Turner zakal...@mac.com 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
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
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, since it
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 sorting issue.
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 low-risk
fix,
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
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
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
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
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
46 matches
Mail list logo
