On Thu, 30 Aug 2012 21:01:31 +0930, Lachlan wrote in message
:
> Hello all.
>
> For those of you that don`t know, me and another developer,
> BluSnowMan (Or Snowman77) are developing
> Flightgear for the popular mobile system Android.
>
> At current the main problem is that it only runs on a f
Tom P wrote:
> Instead of creating a new server for high-end / more detailed sceneries,
> would it be possible to create a branch on the current TerraSync server?
I think that's possible, maybe even just two different directories with
a 'base' Terrain (let's say pure VMap0) and another with the b
Cool, I've just registered, but my Xperia X10 mini pro might be slow...anyway
I'd try
it and let you know.
Thanks
--- On Thu, 8/30/12, Lachlan Bruce wrote:
From: Lachlan Bruce
Subject: [Flightgear-devel] Flightgear on Android
To: flightgear-devel@lists.sourceforge.net
Date: Thursday, Augus
Nice piece of code -- adds some realism
It normally takes longer to retract the gear than to extend. You could also
tweak the times based on air loads, hydraulic pressure, G loads, roll, pitch,
yaw, etc and get down in the weeds on the matter ;-)
Varying transit times based on direction of g
Hello all.
For those of you that don`t know, me and another developer, BluSnowMan (Or
Snowman77) are developing Flightgear for the popular
mobile system Android.
At current the main problem is that it only runs on a few devices. We are
working to expand this and have been building builds for the
Am 30.08.2012 03:51, schrieb castle...@comcast.net:
> Hi,
>
> Is it possible to specify gear up and down transit times for each gear?
> In real airplanes the gear never ( well rarely, maybe ) sequence in
> perfect unison. In reviewing the xml files for the 737, I note there
> are transit times def
Renk Thorsten wrote:
> So, people would like to populate close to the 'real' layout, but
> still do something useful for the scenery database I guess, [...]
You're probably wrong about the second half of your assumption,
Martin.
--
Unix _IS_ user friendly - it's just selective about wh
> I know, some people on the forum would like to eventually replace
> fgfs(.exe) with nasal(.exe), because apparently everything is "just
> better" (tm) when implemented in Nasal (core = bad, nasal = good). But I
> really think this is a completely wrong direction - and harming the
> project.
Co
> Computing constant values at runtime is bad design and we should not do
> that. No matter if we notice a significant increase in load time now or
> not. The ground elevation at a specific point is well known at scenery
> generation time and that is where the vertical position of an object has
> t
9 matches
Mail list logo
