I've noticed that with OSG 3.x, the behaviour of some shaders, especialy in
relation with the alpha channel changed.
Most notable in what is related to this bug:
http://code.google.com/p/flightgear-bugs/issues/detail?id=427
what follows is a copy of my post on that bug report:
Did a bit of test
As soon as i change altitude of some .ac in .stg fgfs hangs at "loading scenery"
No my syntax is ok i can also cut half .stg to load ok but not more.
sighwasted 2 hours on such crap...--
Doing More with Less: The N
As an aside, someone needs to check the runway startup code, I'm sure my cessna
or piper cub started on Helipad 1 at KOAK.
Also will be looking at the golf course texture, it's displaying way too large.
Cheers
John
--
HB-GRAL wrote:
> I see now also some differences between OSM and "our" apt.dat [...]
Note that OSM might be aiming at a different target, they're not
necessarily building a database which meets the specific requirements
in (simulated) aviation.
Cheers,
Martin.
--
Unix _IS_ user friendl
On Wed, Sep 14, 2011 at 12:33 PM, Andreas Gaeb wrote:
> Am 14.09.2011 11:43, schrieb Erik Hofman:
>> I've been pushing this behavior various times and scenery objects should
>> always be positioned at the same location over and over again.
> To clarify things up a bit, not all is broken:
> - Houses
On Sep 13, 2011, at 1:34 PM, James Turner wrote:
>
> On 13 Sep 2011, at 19:53, Adam Dershowitz, Ph.D., P.E. wrote:
>
>> I just downloaded the new 2.4 release for Mac. If I try to launch the app,
>> it just immediately quits.
>> I can successfully run this version of FlightGear from the com
Am 15.09.11 18:12, schrieb Martin Spott:
> HB-GRAL wrote:
>
>> I see now also some differences between OSM and "our" apt.dat [...]
>
> Note that OSM might be aiming at a different target, they're not
> necessarily building a database which meets the specific requirements
> in (simulated) aviation.
Hi all,
I am need of updating my fg data but am finding that the git pull fails
after a while stating that the remote end has disconnected my session.
As this an extremely large download that cannot be interrupted I am just
wasting large amounts of broadband allowance trying to do this.
Is there a
On 09/15/2011 03:08 PM, HB-GRAL wrote:
> No, it looks like the mapping with apt.dat data is inaccurate, at least
> outside the United States.
The following repeats an email I sent quite a while ago,
which somehow seems to have gotten lost:
On 09/10/2011 03:54 PM, HB-GRAL wrote:
> I am just cu
On Fri, Sep 16, 2011 at 12:06 AM, Jason Cox wrote:
> Hi all,
> I am need of updating my fg data but am finding that the git pull fails
> after a while stating that the remote end has disconnected my session.
> As this an extremely large download that cannot be interrupted I am just
> wasting large
On Thursday 15 September 2011 22:08, HB-GRAL wrote:
> No, it looks like the mapping with apt.dat data is inaccurate, at least
> outside the United States.
>
> I checked some airports the last days. You can not say that FlightGear
> or X-Plane data is accurate and the rest of the mapping world is
>
On 09/15/2011 05:15 PM, Martin Fenelon wrote:
> I like to think that the positional errors of many (most non US?)
> aerodromes are due to mistakes made when changing from one datum to
> another.
Well, that's not what I think, based on looking at
the data.
The very first non-US example I look
Right -- outside the USA, much of the x-plane airport data is hand entered
and submitted by end-users with no quality control other than people are
welcome to research and fix problems they find as they find them. I
wouldn't be surprised if some of the entries are complete guesses or crazy
typos.
13 matches
Mail list logo
