Whoops! I've recreated your problem and I'll try to get a fix out soon.
Tim
Durk Talsma wrote:
Hi All,
After today's CVS update (~8:00AM, CET), I'm only seeing approximately 10
meters of scenery around me, using my customized camera setup (attached
below). The more distant scenery is
Tim Moore wrote:
Yeah, the lack of frame buffer object support turned out to be the common
denominator for users seeing the problem. I checked in code tonight that
should
resolve the issue when frame buffer objects aren't available.
Great stuff - thanks Tim.
I wonder whether it would be
An early 1.9.1 ?
-Fred
-- message original --
Sujet: Re: [Flightgear-devel] Big black box
De: Stuart Buchanan stuart_d_bucha...@yahoo.co.uk
Date: 31.12.2008 09:51
Tim Moore wrote:
Yeah, the lack of frame buffer object support turned out to be the common
denominator for users
Hi,
On Wednesday 31 December 2008 11:11:16 Frederic Bouvier wrote:
An early 1.9.1 ?
-Fred
-- message original --
Sujet:Re: [Flightgear-devel] Big black box
De: Stuart Buchanan stuart_d_bucha...@yahoo.co.uk
Date: 31.12.2008 09:51
Tim Moore wrote:
Yeah, the lack of
Fred wrote
An early 1.9.1 ?
-
-- message original --
Sujet:Re: [Flightgear-devel] Big black box
De: Stuart Buchanan stuart_d_bucha...@yahoo.co.uk
Date: 31.12.2008 09:51
Tim Moore wrote:
Yeah, the lack of frame buffer object support turned out to be the
common
On 31 Dec 2008, at 10:50, Vivian Meazza wrote:
On the other hand, there has been a recent and significant
improvement in
frame rate. I'm not sure if it's Yon's, Tim's or James' stuff, but
well done
all.
I'd love to take credit, but I don't *think* it can be me - I've made
some
Hi Durk,
my intention is to post a win32 binary update as soon as the issues reported by
Vivian and you are addressed. I don't think the new commited code requires a
data update.
-Fred
-- message original --
Sujet: Re: [Flightgear-devel] Big black box
De: Durk Talsma d.tal...@xs4all.nl
On 31 Dec 2008, at 10:11, Frederic Bouvier wrote:
An early 1.9.1 ?
I think we need to get a handle on the 'scenery loading takes 2
minutes' issue before doing a 1.9.1
Completely wild guess - hitting a slow path in OSG or the driver due
to some missing feature / unsupported extension?
Whoops! I've recreated your problem and I'll try to get a fix out soon.
Tim
Durk Talsma wrote:
Hi All,
After today's CVS update (~8:00AM, CET), I'm only seeing approximately 10
meters of scenery around me, using my customized camera setup (attached
below). The more distant scenery is
Hi,
On Wed, Dec 31, 2008 at 12:06 PM, James Turner zakal...@mac.com wrote:
I think we need to get a handle on the 'scenery loading takes 2
minutes' issue before doing a 1.9.1
Some weeks ago I was looking around the database thread and
I got the impression all --random-objects are getting
Fred wrote
Hi Durk,
my intention is to post a win32 binary update as soon as the issues
reported by Vivian and you are addressed. I don't think the new commited
code requires a data update.
-Fred
-- message original --
Sujet:Re: [Flightgear-devel] Big black box
De: Durk
On 31 Dec 2008, at 11:28, Yon Uriarte wrote:
I havent cvs updated in a few days, but merging both
the use OpenThreads atomic and use display lists for
shader trees would benefit win32 users and general fps.
I'll see if I can merge soon and repost a patch.
I've tested both locally, and
(sorry for the long email, but please read if you are involved with
panel creation, or can shed light on nav-radios)
I have had an entertaining afternoon, and now morning, with the Mk-VIII.
Along the way, I believe I have discovered some genuine bugs in the
code, and some odd assumptions
On 31 Dec 2008, at 13:09, James Turner wrote:
...as giving a value of 0.32 degrees GS deviation per dot. I'd love to
know if this is correct, and what the VOR/HSI deviation is (in degrees
per dot) (I believe the 'LOC is 4x the sensitivity of VOR' rule is
indeed correct, but again, please
James Turner wrote
On 31 Dec 2008, at 11:28, Yon Uriarte wrote:
I havent cvs updated in a few days, but merging both
the use OpenThreads atomic and use display lists for
shader trees would benefit win32 users and general fps.
I'll see if I can merge soon and repost a patch.
Here's the patch again:
referenced.patch
Description: Binary data
We don't really want to becommittingpatches that add #ifdef control variables - if everyone agrees the OpenThreads primitives are the way to go, we should switch permanently, not support both. But in the short term it's a good way
Installing that, thanks.
-Original Message-
From: James Turner [mailto:zakal...@mac.com]
Sent: 31 December 2008 14:09
To: FlightGear developers discussions
Subject: [Flightgear-devel] Yon's SGReferenced patch.
Here's the patch again:
Installed OK and runs. There seems to be an appreciable improvement in load
time. Loading Scenery objects now takes a disproportionate time. However,
I'm now getting segfaults on loading MP players. I can't track it down to
any particular ac, nor is it clear if this is associated with Yon's patch
On 12/31/2008 06:23 AM, James Turner wrote:
Reckons 5 degrees per-dot for a VOR, 1.25 for a LOC (yay, the 4x
factor is sane) and 'about a quarter of a degree per dot' for a GS
indicator, so the 0.32 term is plausible.
Standard dogma in IFR training is that the VOR CDI indicates
two
Now that the release is out, my I add a little reminder to this patch
which was meant to add some 'cleanup' to SimGear's use of threading
libraries:
http://blaniel.free.fr/pub/flightgear/patches/ot_simgear.patch
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about
On 31 Dec 2008, at 17:38, Martin Spott wrote:
Now that the release is out, my I add a little reminder to this patch
which was meant to add some 'cleanup' to SimGear's use of threading
libraries:
http://blaniel.free.fr/pub/flightgear/patches/ot_simgear.patch
That patch is entirely
I have a pretty-much workable workaround for the worst
of these bugs.
The big clue is that presets-commit apparently just
deletes the old FDM instance and creates another.
To make the new FDM happy, I had to delete a bunch
of nodes from the property tree. Some other nodes
needed to be set to
The way this was explained to me is that JSBSim only performs the wow test
when it is within 200' of the ground. Unfortunately, this means that if you
start in the air higher than that, the gear variables can be left in an
unsettled state because the test that sets the variables never gets run.
On 12/31/2008 11:20 AM, Curtis Olson wrote:
The way this was explained to me is that JSBSim only performs the wow test
when it is within 200' of the ground. Unfortunately, this means that if you
start in the air higher than that, the gear variables can be left in an
unsettled state because
On Wed, Dec 31, 2008 at 12:35 PM, John Denker j...@av8n.com wrote:
On 12/31/2008 11:20 AM, Curtis Olson wrote:
The way this was explained to me is that JSBSim only performs the wow
test
when it is within 200' of the ground. Unfortunately, this means that if
you
start in the air higher
On 12/31/2008 10:29 AM, I wrote:
Standard dogma in IFR training is that the VOR CDI indicates
two degrees per dot, while the LOC CDI indicates half a degree
per dot. These numbers are quite believable. Good practice
is to check them as part of the 30-day IFR receiver check.
Important
James Turner wrote:
On 31 Dec 2008, at 17:38, Martin Spott wrote:
Now that the release is out, my I add a little reminder to this patch
which was meant to add some 'cleanup' to SimGear's use of threading
libraries:
http://blaniel.free.fr/pub/flightgear/patches/ot_simgear.patch
That
On 31 Dec 2008, at 19:32, Martin Spott wrote:
Do/merge/leave whatever/however you like, I just wanted to make sure
Daniel's changes don't get lost.
Right, thanks for clarifying. I'm happy to apply the still-relevant
parts of this, and Yon's SGReferenced patch, but I want a positive
Martin Spott wrote:
I was aware that a part of Daniel's changes [...]
^^
Sorry for my confusion, the author of the respective patch is Benoit
Laniel,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
On Wed, 2008-12-31 at 12:20 -0600, Curtis Olson wrote:
The way this was explained to me is that JSBSim only performs the wow
test when it is within 200' of the ground. Unfortunately, this means
that if you start in the air higher than that, the gear variables can
be left in an unsettled state
--
revision 1.3
date: 2008/12/04 18:47:49; author: mfranz; state: Exp; lines: +1 -1
Allow negative thrust. This allows a single recoil or vibration
thruster to accelerate in both directions. THROTTLE input still
clamps to 0/1 by default. (OK'ed by Andy)
On 12/31/2008 06:22 PM, Ron Jensen wrote:
for what its worth, the in-air dialog could
set /fdm/jsbsim/gear/unit[*]/WOW to false.
I thought of that.
It doesn't work.
The FDM rewrites the wow property at frame rate,
forcing it to 1.
Why it is so insistent on writing a value to the
On Wed, 2008-12-31 at 20:07 -0700, John Denker wrote:
On 12/31/2008 06:22 PM, Ron Jensen wrote:
for what its worth, the in-air dialog could
set /fdm/jsbsim/gear/unit[*]/WOW to false.
I thought of that.
It doesn't work.
Yes, it does.
The FDM rewrites the wow property at frame
John Denker wrote:
I've always thought the 200-ft business was a weird optimization,
especially since other properties such as gear-extension-norm
are recomputed at frame rate at all altitudes. And that is
the solution for retractable-gear airplanes: forget about wow
and just look at
John Denker wrote:
On 12/31/2008 10:29 AM, I wrote
Standard dogma in IFR training is that the VOR CDI indicates
two degrees per dot, while the LOC CDI indicates half a degree
per dot. These numbers are quite believable. Good practice
is to check them as part of the 30-day IFR receiver
35 matches
Mail list logo
