Gary adressed those creating the 3d-models and aircraft in FGFS.
Yes, quite. And since your own aircraft doesn't repeat and is there
independent of visibility range, so in some sense this is a special case
anyway.
Problem is, once you have created a model, you don't control what others
do with
Hi,
While working to add support for realistic radio capabilities of navradio
equipment, I have transitioned the radio code to a subsystem, thanks to
valuable advice from Torsten, which should remove performance issues and make
the system more flexible and useful for other development, like
On Mon, 6 Feb 2012 07:39:22 -0800 (PST), Gene Buckle wrote:
On Mon, 6 Feb 2012, Chris Wilkinson wrote:
http://flightsimulatorplus.com/terms.html
Seems FSP or PFS or FPS or whatever has reinvented itself - that
link
showed on my Facebook page just now for the first time in perhaps 6
Stuart Buchanan wrote:
I've just committed to simgear/next and fgdata/master code to allow
the placement and rotation of random objects and vegetation to be
masked based on a bitmap.
That's a nice approach !
From my perspective the meaning of the different properties
tree-density and
On Tue, Feb 7, 2012 at 4:15 PM, Martin Spott wrote:
Stuart Buchanan wrote:
I've just committed to simgear/next and fgdata/master code to allow
the placement and rotation of random objects and vegetation to be
masked based on a bitmap.
That's a nice approach !
From my perspective the
Hi Adrian,
Would go with 1. As you say signal strength does not have a major
influence on the functionality itself. It works or you have a flag. Only
of the very border of reception the respective indicator will wander
out. But that also is a signal strength issue and can be modelled
Stuart Buchanan wrote:
On Tue, Feb 7, 2012 at 4:15 PM, Martin Spott wrote:
From my perspective the meaning of the different properties
tree-density and wood-coverage gets a little bit confusing, but
I'd probably leave fiddling with the new values to those with more
powerful hardware =A0;-)
Hi all
Is it a good or bad idea for the FGx launcher to check against the
version file if it is a valid fgdata folder AT ALL ? I will need some
kind of check.
In case it is a bad idea, do you have other suggestions ?
(Sorry for the dumb question but thanks in advance for your comments).
-Yves
On 07.02.2012 21:13, HB-GRAL wrote:
Is it a good or bad idea for the FGx launcher to check against the
version file if it is a valid fgdata folder AT ALL ? I will need some
kind of check.
Seems a good idea. Same check is hard-coded inside fgfs (of course, fgfs
also requires correct content of
On Tue, Feb 7, 2012 at 2:29 PM, ThorstenB bre...@gmail.com wrote:
On 07.02.2012 21:13, HB-GRAL wrote:
Is it a good or bad idea for the FGx launcher to check against the
version file if it is a valid fgdata folder AT ALL ? I will need some
kind of check.
Seems a good idea. Same check is
Am 07.02.2012 21:34, schrieb Curtis Olson:
The main reason for a version check between the binary and the data is
that we often make parallel changes to both (similar reason why we do a
simgear minimum version check when compiling flightgear.) If there are
version mismatches, things could
On Tue, Feb 7, 2012 at 5:04 PM, Martin Spott wrote:
Stuart Buchanan wrote:
On Tue, Feb 7, 2012 at 4:15 PM, Martin Spott wrote:
From my perspective the meaning of the different properties
tree-density and wood-coverage gets a little bit confusing, but
I'd probably leave fiddling with the new
Stuart Buchanan wrote:
On Tue, Feb 7, 2012 at 5:04 PM, Martin Spott wrote:
They _are_ being used, anyhow, retiring the old values and transferring
the respective meaning into their 'modern' counterparts whould
facilitate understanding of what's going on for those who don't deal
with this
How does one develop an autoland system atop that ?
As I understand it the localiser signal is always pretty accurate in CAT3
protected ILS..
But the glideslope should be unreliable from 150ft ish which is why there
is a decision height ie runway in sight..
My basic question is actually, is
14 matches
Mail list logo