On Fri, Jan 04, 2008 at 07:45:42PM +0100, Csaba Hal?sz wrote:
On Jan 2, 2008 3:01 PM, Holger Wirtz [EMAIL PROTECTED] wrote:
I have upgraded Asterisk to version 1.4. The conferences should now have
an auto-mute feature: onlay one (the first) person can speak.
Looks like something is
Hi!
LeeE wrote:
I think I mentioned earlier, but first problem - there's no SRTM
data for the poles. Second problem is that calculations that
assume a quad (trapezoidal) area fail at the poles because they
have to deal with a tri area and not a quad area.
The problem is not that tiles
On Sun, 6 Jan 2008 23:00:22 +
LeeE wrote:
Can anyone else confirm this problem on the OSG cvs branch?
Yes, I see it too, and have for at least a couple of weeks.
-c
--
Chris Metzler [EMAIL PROTECTED]
(remove snip-me. to email)
As a child I understood
Lee wrote
Subject: Re: [Flightgear-devel] Nasal error with YASim
aircraft having 4fuel tanks
On Friday 04 January 2008 19:59, LeeE wrote:
Hi all,
I just noticed I was getting a Nasal error with a YASim
aircraft I was
working on that had only three fuel tanks. The error is:
Hi again!
Thinking a bit more about it, the grid could be made consistent if we
would define that 180W and 180E are tile borders instead of enforcing
the Greenwich Meridian to be a tile border at all ranges of latitude.
Find attached my proposed patch.
That would change the arrangement of tiles
Tim Moore wrote:
I've checked this work in, with a change to use an independent quad tree
builder class.
Thanks very much for the contribution; it's good to have another OSG hacker
in the
house.
With the latest version of FlightGear I got it to hang while loading the
scenery objects and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Erik Hofman wrote:
Tim Moore wrote:
I've checked this work in, with a change to use an independent quad tree
builder class.
Thanks very much for the contribution; it's good to have another OSG hacker
in the
house.
With the latest version
On Jan 7, 2008 9:24 AM, Tim Moore [EMAIL PROTECTED] wrote:
If you are going to enable random objects, I recommend using OSG 2.3 or
later. Otherwise,
set the environment variable OSG_DATABASE_PAGER_DRAWABLE=VertexArrays
Hi Tim,
Is there a way to work around this in our code? Right now OSG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Curtis Olson wrote:
On Jan 7, 2008 9:24 AM, Tim Moore [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
If you are going to enable random objects, I recommend using OSG 2.3
or later. Otherwise,
set the environment variable
On Monday 07 January 2008 10:55, Vivian Meazza wrote:
[snip...]
Out of the candidates I tested only the a4f, which appears to
be based on the a4, didn't have the problem - I haven't looked
into this discrepancy yet.
Can anyone else confirm this problem on the OSG cvs branch?
The A4F
On Monday 07 January 2008 11:07, Chris Metzler wrote:
On Sun, 6 Jan 2008 23:00:22 +
LeeE wrote:
Can anyone else confirm this problem on the OSG cvs branch?
Yes, I see it too, and have for at least a couple of weeks.
-c
Thanks - confirms it's not just a local problem here.
LeeE
On Monday 07 January 2008 18:24, LeeE wrote:
On Monday 07 January 2008 11:07, Chris Metzler wrote:
On Sun, 6 Jan 2008 23:00:22 +
LeeE wrote:
Can anyone else confirm this problem on the OSG cvs branch?
Yes, I see it too, and have for at least a couple of weeks.
-c
Thanks -
LeeE wrote:
On Monday 07 January 2008 18:24, LeeE wrote:
On Monday 07 January 2008 11:07, Chris Metzler wrote:
On Sun, 6 Jan 2008 23:00:22 +
LeeE wrote:
Can anyone else confirm this problem on the OSG cvs branch?
Yes, I see it too, and have for at least a couple
On Jan 7, 2008 5:10 AM, Ralf Gerlich [EMAIL PROTECTED] wrote:
Thinking a bit more about it, the grid could be made consistent if we
would define that 180W and 180E are tile borders instead of enforcing
the Greenwich Meridian to be a tile border at all ranges of latitude.
Find attached my
Selon Curtis Olson :
I've been wondering about dispensing with the variable subdivision scheme
and just having a fixed number of divisions per 1 degree of longitude.
Perhaps having 4 subdivisions. This would double the tile width at the
equator, but would preserve the same tile widths in the
As I said in a previous message, fgrun is now internationalized, and the french
localisation is done.
I am now seeking for volunteers that are willing to translate fgrun in their
native language. People are invited to contact me by private mail so that I can
coordinate these efforts, and to get
Berndt, Jon S wrote:
Unfortunately, the supporting code is not part of the JSBSim
baseline so it is impossible to see how it works , although
it has been submitted a while back. You can see the
supporting source changes by downloading the tar file of the
code used at a Mathworks expo and will
Hi,
On Monday 31 December 2007, alexis bory wrote:
A very easy way to check if the offset is applied, is looking at the
A-10's fuel gauge (right side of the main panel),when offline,
its drum counter should display 0 instead of 1.
Thanks!
Ok, should work now.
Greetings
Mathias
On Jan 7, 2008 3:51 PM, Frederic Bouvier wrote:
If we keep the same triangle budget for every tile, we will have sparse
data and
features at the equator and much more than what is really needed at the
poles,
just because the area covered by each tile will vary greatly (
proportional to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Curtis Olson wrote:
My gut feeling is that once you get up (or down) into the latittudes where
the tiles get significantly skinny, the resolution of the available data
drops of significantly. We really don't have a per-tile triangle budget
On Monday 07 January 2008 20:00, John Wojnaroski wrote:
LeeE wrote:
On Monday 07 January 2008 18:24, LeeE wrote:
On Monday 07 January 2008 11:07, Chris Metzler wrote:
On Sun, 6 Jan 2008 23:00:22 +
LeeE wrote:
Can anyone else confirm this problem on the OSG cvs branch?
Yes, I see it
On Monday 07 January 2008 22:28, Curtis Olson wrote:
On Jan 7, 2008 3:51 PM, Frederic Bouvier wrote:
If we keep the same triangle budget for every tile, we will
have sparse data and
features at the equator and much more than what is really
needed at the poles,
just because the area
On Monday 07 January 2008, dave perry wrote:
2. Some aircraft-defined keyboard toggles work only once in osg branch
Examples: pa24-250-set.xml and the pa28-161 both use the keys !,
@, #, $, %, ^, (, and ). With older osg builds and
current V1.0 and plib builds these work. With
Selon Curtis Olson :
On Jan 7, 2008 3:51 PM, Frederic Bouvier wrote:
If we keep the same triangle budget for every tile, we will have sparse
data and
features at the equator and much more than what is really needed at the
poles,
just because the area covered by each tile will vary
24 matches
Mail list logo
