Durk Talsma wrote:
I agree, but for display purposes just loading a memory image of the Robin
Peel database would probably suffice. I.e. there wouldn't be a need for
setting up an intricate network of nodes and connections as I'm currently
doing for the ground network. Therefore, I'm
Hello Erik,
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/tests
In directory baron:/tmp/cvs-serv19690
Modified Files:
Makefile.am
Added Files:
al-info.c
Log Message:
Add a gl-info equivalent for OpenAL.
Does this test rely on the recent OpenAL CVS or
Martin Spott wrote:
Hello Erik,
Does this test rely on the recent OpenAL CVS or should it compile with
the 'stable' from April last year as well ? I'm asking because my
compiler barks and I thought you'd run this on the same platform as I
do:
I run the latest CVS version of OpenAL.
I've
I am trying to build FG using cygwin. Have followed all the instructions in
the fgfs_cygwin.pdf about building the required packages prior to building
FlightGear. They were all built with no errors and with a resulting
directory structure exactly the same as shown in the instructions. But
Chris Millichamp schrieb:
Hi
I am trying to build FG using cygwin. Have followed all the instructions
in the fgfs_cygwin.pdf about building the required packages prior to
building FlightGear. They were all built with no errors and with a
resulting directory structure exactly the same as
Hello Erik,
Erik Hofman wrote:
I run the latest CVS version of OpenAL.
Which trick do you use to get the aut-tools working ? They don't work
for me with OpenAL CVS. This one reason is why I recommend to stick
with the older OpenAL source.
I've updated al-info.c to fix those problems and
Hi again.
The more I am thinking about a clean way to implement proper rain cone
tilting at any view origin, the more difficult it seems. I've already
made it work properly for views attached to flying aircraft (such as
in-cockpit/chase/helicopter view), and would love to make it work for
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Georg
Vollnhals
Sent: 01 February 2006 16:16
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] SimGear support library not found
Chris Millichamp schrieb:
Hi
I am trying
Chris Millichamp wrote :
Hi there.
I've tried what you just said and I still get the same error message. It
checks for SimGear version.h and doesn't find it and so configuration is
aborted. Have been trying for two days to build this thing and am getting
rather fed up of it all!
Once
Martin Spott wrote:
Hello Erik,
Erik Hofman wrote:
I run the latest CVS version of OpenAL.
Which trick do you use to get the aut-tools working ? They don't work
for me with OpenAL CVS. This one reason is why I recommend to stick
with the older OpenAL source.
Sigh, yes it's a real pain
Eric,
We use one prop /controls/gear/gear-down to denote when gear is down and
locked. does YASim just turn on the extra drag when that changes to 1 or
does it slowly increase it over the time of extension?
Josh
---
This SF.net email is
Josh Babcock wrote:
We use one prop /controls/gear/gear-down to denote when gear is down
and locked. does YASim just turn on the extra drag when that changes
to 1 or does it slowly increase it over the time of extension?
It's smoothly interpolated across the extension.
Andy
FYI on Scale4x
On another note, WebmasterRadio (www.webmasterradio.fm) will be doing a
special show profiling this year's conference. It will be on the air
on Feb 2nd at 3pm EST.
JW
---
This SF.net email is sponsored by: Splunk Inc. Do
I noticed that the Piper Warrior II (pa28-161) YASim flight model is
no longer converging. The model itself hasn't been touched since
2004, and it was working a couple of months ago, so I'll guess that
recent YASim code changes have broken it. Here's what I get with
--log-level=debug:
WARNING:
David Megginson wrote:
I noticed that the Piper Warrior II (pa28-161) YASim flight model is
no longer converging. The model itself hasn't been touched since
2004, and it was working a couple of months ago, so I'll guess that
recent YASim code changes have broken it. Here's what I get with
Looks like interpolations in (at least) rotate animations fail if the
ind entries are not in increasing order. I'm pretty sure that it didn't
used to be that way. Is this intended or a bug?
Josh
---
This SF.net email is sponsored by: Splunk
16 matches
Mail list logo
