I have added a couple of small indicators to the standard HUD, with the same
format as that used for the pitch trim indicator. Attached is a patch with my
small modification. It's really quite a small modification, but I find it
useful mainly for helicopters, and since it's of little consequenc
This is nitpicking. The original files are released under the GPL v2 terms.
That licence cannot be revocated by anyone, not even by the author, though he
may choose to re-release the files with another licence. The terms of the
unmodified GPL v2 allow the relicencing by 3rd parties with subsequ
Hi Thorsten,
I suspect I know what is actually happening, at least it also happend on my
Thrustmaster Cougar.
Just try this: move all axes on the joystick to all extremes before starting
FG.
I think you are hitting on an autocalibration issue. It might be the OS or even
the joystick's own hard
Actually, I find it rather odd that it should have all this trouble to climb in
an hover at sea level. I love the Bo105, it's my plane of choice, but making a
neat vertical take off is very hard.
Alessandro
> Date: Sun, 17 Apr 2011 21:37:42 +0100
> From: aeitsch...@yahoo.de
> To: flightgear-de
I have applied a couple of small modifications to the script to fix FGCOM and
ATLAS compilation with the current repository versions of both. The changes are
relatively small, just a couple of sed rule changes for the FGCOM makefile and
a renamed function in ATLAS to match the updated SimGear.
That's 519 possible culprits. It will take 10 compiles to find the exact
revision by successive approximations.
> Date: Wed, 18 May 2011 08:45:11 +0200
> From: bre...@gmail.com
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268
>
>
ear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] Modified download_and_compile.sh script
>
> On 18.05.2011 01:08, TDO_Brandano - wrote:
> > I have applied a couple of small modifications to the script to fix
> > FGCOM and ATLAS compilation with the current repository ver
How hard would it be to change the background colour based on the camera
altitude? Even a linear gradient between two set points would work, I think.
> Date: Wed, 18 May 2011 22:41:54 +0200
> From: bre...@gmail.com
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] T
I think that the best setup would use a broken line rather than a simple linear
ramp, to show actual transition outside of atmospheric flight. Would something
like that affect performance much?
Alessandro
> From: lauri.pelto...@gmail.com
> To: flightgear-devel@lists.sourceforge.net
> Date: Th
Ok, before I get flamed to a crisp, let me explain what is my reasoning behind
this. Right now the fgdata repository is about 9 GB. This makes it really,
really difficult to obtain an initial checkout of the fgdata folder, expecially
for people that do not have a very good connection. at the sa
1 17:41:36 +0200
> From: flightg...@sablonier.ch
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
>
> Am 24.06.11 12:55, schrieb Erik Hofman:
> > On Fri, 2011-06-24 at 10:48 +, TDO_Brandano - wrote:
>
If the scope is to show off the capabilities, I'd really consider the IAR-80
too.
Alessandro
> Date: Mon, 4 Jul 2011 12:50:57 +0300
> From: thorsten.i.r...@jyu.fi
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] Aircraft selection for 2.4.0
>
> > We currently have
Perhaps someone should mention to Renè the standard procedures to get a script
included in dthe official ones distributed along with Blender. The page with
the details is http://wiki.blender.org/index.php/Dev:Py/Sharing , but I'd
prefer if someone could translate this in a meaningful French and
I wouldn't touch the Vostock right now, it might be taken as an afront by the
author
Alessandro
> Date: Thu, 4 Aug 2011 09:50:04 +0200
> From: tors...@t3r.de
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
>
> > Sound
try running download_and_compile.sh (-an -pn) DATA
the -an switch disables the apt-get update, and -pn disables the apt-get
upgrade, you won't really need those for the data anyway.
Alessandro
> Date: Thu, 4 Aug 2011 09:59:29 -0400
> From: marth...@yahoo.ca
> To: flightgear-devel@lists.sourcef
Hmm, well, the FGRUN tool could do with several fixes, I think. I suspect that
by now a complete rewrite might be better, though. This sort of properties that
do not require a restart of the simulator could be set through a socket even at
runtime rather than being fed as a command line switch,
Well, if you know how to write a simple program you could try accessing and
setting the properties through the telnet protocol with a wrapper application,
and communicate with that one through the serial port. As far as I know the
telnet protocol works bidirectionally with FG without issues.
The simplest way is to edit that line of code and compile FGFS. After 2.4 is
out this might get implemented by the committers, and then you could grab a
precompiled binary from the Hudson/Jenkins automatic build system. In any case
a little patience seems to be the only essential requirement.
I'd also add, incidentally, that creating your own repo automatically gives you
commit rights to it as well. Though it would be nice to stick to some
guidelines to ensure compatibility, like tagging the plane repo to match FGFS
tags
Alessandro
> Date: Fri, 12 Aug 2011 13:02:16 +0200
> From: t
There are several ways to send an input to FlightGear. The example that sprinsg
most readily to my mind is the way LinuxTrack can communicate head tracking
position to FGFS.
Essentially either writing the values for camera position via a protocol file
(look in fgdata/Protocols) or sending the d
the key for input? 发件人: TDO_Brandano - [mailto:tdo_brand...@hotmail.com]
发送时间: 2011年8月14日 23:29
收件人: Flightgear Devel List
主题: Re: [Flightgear-devel] FG Input though socket or anyway? There are several
ways to send an input to FlightGear. The example that sprinsg most readily to
my mind is the
BTW, you can get a pretty good idea of where the CG is on a plane from the
landing gear position. On a tail dragger the CG will be slightly behind the
main wheel. Too far back and the tail won't have enough authority to lift for
takeoff, too far forward and the plane will nose over when braking
Actually I bought an "el cheapo" (EKEN m009s) android tablet for the explicit
purpose of trying to use it as a rudimentary MFD, exploiting also the touch
screen interface. Currently I am playing a bit with HTML5 features, but a
native implementation would probably be better and would free up CP
Sorry, but closing the content would be against the spirit of a GPL project.
Also, reverse engineering to allow interoperability of formats is expressely
allowed in the DMCA. The content is protected by copyright law, that ought to
be enough. If plane developers are interested in creating conte
Not really, or Openoffice/Staroffice/Libreoffice would not be able to open
Microsoft formats.
Here is what section (f) of Chapter 12 of the DMCA has to say to the regard :
(f) Reverse Engineering. — (1)
Notwithstanding the provisions of subsection (a)(1)(A), a person who has
lawfully
obta
I have also had this error, building on Ubuntu 10.10 AMD64. I think it might
have been an update in either SimGear or OSG, but I did not follow it up
because my older FGRUN build was still running fine
> From: ubu...@geoffair.info
> To: flightgear-devel@lists.sourceforge.net
> Date: Thu, 8 Sep
Perhaps there ought to be some sort of keybind conflict check. Ideally it would
prompt the user to choose an alternative, but that's probably utopia.
Alessandro
> From: zakal...@mac.com
> Date: Tue, 20 Sep 2011 20:53:34 +0100
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightge
if you just want to discard EVERYTHING back to the head version (make sure you
are on the master branch) try this: git checkout -- .
the full stop is part of the command, btw
Alessandro.
From: curtol...@gmail.com
Date: Tue, 27 Sep 2011 10:25:56 -0500
To: flightgear-devel@lists.sourceforge.net
S
Personally, I'd prefer Python, mainly because its garbage collection seems to
work fine and it has a large base library, with many third party modules to
extend on it. But, as someone pointed out earlier here, you can't always get
what you want...
Ciao,
Alessandro
> Date: Fri, 7 Oct 2011 14:0
Really, couldn't we just split off all the aircrafts to a separate SVN
repository? Or to several GIT repositories? That way they could be checked out
individually. I don't think we need the level of detailed history that GIT
provides when it comes to aircraft data, and that way it would be poss
I guess that the aircrafts will just end up "deleted" in the next pull, leaving
the rest of FGDATA untouched. However, FGFS already supports a different path
for aircrafts, so it should be pretty simple to get everything running as
usual. Just copy the planes to another folder before the next p
Not automatically, as far as I know, but it should be relatively simple to
script this. the main issue is how to script something that will work across
platforms. I can do this in less than 20 lines of python, but of course not
everyone has python installed on his windows machine
Ciao,
Alessa
The greatest problem i can see is that there's no wget equivalent for Windows,
or tools to parse strings from a file, inbuilt in the shell. That's why I was
mentioning python: it's easier to get working on Windows and these tools are
part of the standard library. On linux, of course, you can ge
like precompiled
packages. Maybe we can do this serverside, let them check a box for each
aircraft or select all and simply give them a link?
Jorg
2011/10/19 TDO_Brandano -
The greatest problem i can see is that there's no wget equivalent for Windows,
or tools to parse strings from a
34 matches
Mail list logo
