On 21 Jul 2010, at 01:15, Alex Romosan wrote:
i noticed something even stranger. for me, if the aircraft file matches
the directory name then i can load it using --aircraft=aircraft syntax
(tried it with f16, f-14b, b1900d and some others). if it doesn't (p61
and x35) then i get:
Cannot
Hi James,
for me, updated GIT version from this morning, the p61 works fine. :)
But BTW: --show-aircraft gives me a strange listing:
- SNIP ---
Available aircraft:
14bis-set.xml14bis Santos DUMONT
21-set.xml Santos Dumont N 21 Demoiselle
On 21 Jul 2010, at 08:02, Roland Haeder wrote:
But BTW: --show-aircraft gives me a strange listing:
- SNIP ---
Available aircraft:
14bis-set.xml14bis Santos DUMONT
21-set.xml Santos Dumont N 21 Demoiselle
707-set.xml Boeing
On 20 Jul 2010, at 23:14, James Turner wrote:
I get the same parsing error in Linux if a Aircraft-Directory is linked
(Soft-
Link) to fgdata/Aircraft. If I copy this Aircraft-Directory directly into
fgdata/Aircraft everything works fine. A few days ago the linked Aircraft
was still
Debugging on my windows boxes fg_init.cxx line 21 is reached.
if (_foundPath.str().empty()) {
SG_LOG(SG_GENERAL, SG_ALERT, Cannot find specified aircraft:
aircraft );
return false;
aircaftDir is {path=C:/Flightgear/fgdata/Aircraft}
aircraft is
On 21 Jul 2010, at 09:24, Alan Teeder wrote:
Debugging on my windows boxes fg_init.cxx line 21 is reached.
if (_foundPath.str().empty()) {
SG_LOG(SG_GENERAL, SG_ALERT, Cannot find specified aircraft:
aircraft );
return false;
aircaftDir is
Hi Curt,
I have checked the submodel wind. The calculations appear to be correct, and
submodels seem to move in the direction indicated by the windsock. So if
there's an error there it's at least consistent. Using submodels as
contrails (which doesn't give a particularly good appearance) they
Curt,
A further update - here is the error illustrated:
ftp://abbeytheatre2.org.uk:2121/flightgear/Particles/particle-wind.jpg
The red spheres are submodels with wind activated. I would say that they are
reacting as expected. The contrail consists of particles with wind
activated. The
--
From: James Turner zakal...@mac.com
Sent: Wednesday, July 21, 2010 9:51 AM
To: FlightGear developers discussions
flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] aircraft search
On 21 Jul 2010, at 09:24, Alan Teeder
On 21 Jul 2010, at 11:40, Alan Teeder wrote:
and the result was:
fgFindAircraftInDir: no such path:C:/Flightgear/fgdata/Aircraft
Single stepping the debugger showed that fopen in simgear SGPath::exists()
failed.
Interesting - I only discovered this morning that SGPath::exists() uses
Hello,
Can I just ask what version of OpenSceneGraph is required to compile and
run Flightgear/Simgear (v2.0.0). The release page suggests that any
version will do however newer versions =2.9.6 will run better but is
this the case? Will the latest stable release of OpenSceneGraph (2.8.3)
do?
On 21 Jul 2010, at 14:01, Chris Baines wrote:
Can I just ask what version of OpenSceneGraph is required to compile and
run Flightgear/Simgear (v2.0.0). The release page suggests that any
version will do however newer versions =2.9.6 will run better but is
this the case? Will the latest
James Turner ja...@bugless.co.uk writes:
Can you email me what you get for --show-aircraft? (off list, is best)
fgfs --show-aircraft
Available aircraft:
(that is nothing). this on linux.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the
On Wed, Jul 21, 2010 at 3:54 AM, Vivian Meazza wrote:
Curt,
A further update – here is the error illustrated:
ftp://abbeytheatre2.org.uk:2121/flightgear/Particles/particle-wind.jpg
The red spheres are submodels with wind activated. I would say that they
are reacting as expected. The
Hi Curt, and Torsten
My initial investigations have turned up this in environment_mgr.cxx :
osg::Vec3 windVec(-_environment-get_wind_from_north_fps(),
-_environment-get_wind_from_east_fps(),
_environment-get_wind_from_down_fps());
Hi James,
On Wednesday, July 21, 2010 05:39:08 pm James Turner wrote:
My hypothesis is that something in the AI-Traffic code doesn't like being
re-positioned; if I reset/re-position very rapidly, I don't usually crash,
whereas if I wait 20-30 seconds at a location, before re-positioning, the
On 21 Jul 2010, at 18:47, Thorsten wrote:
My hypothesis is that something in the AI-Traffic code doesn't like being
re-positioned;
Maybe related to issue #133 in bug tracker:
http://code.google.com/p/flightgear-bugs/issues/detail?id=133
The AI code corrupts memory when the plane leaves
On 21 Jul 2010, at 19:37, Durk Talsma wrote:
My hypothesis is that something in the AI-Traffic code doesn't like being
re-positioned; if I reset/re-position very rapidly, I don't usually crash,
whereas if I wait 20-30 seconds at a location, before re-positioning, the
crash is much more
On Wednesday, July 21, 2010 08:42:49 pm James Turner wrote:
The old code. I'm going to try Thorsten's patches in #133, but a related
question - could we not make --disable-atcdcl the default? (I.e,
--enable-atcdcl instead)
I'm actually strongly considering this; however, the current
James Turner wrote:
On 21 Jul 2010, at 19:37, Durk Talsma wrote:
My hypothesis is that something in the AI-Traffic code doesn't like being
re-positioned; if I reset/re-position very rapidly, I don't usually crash,
whereas if I wait 20-30 seconds at a location, before re-positioning, the
Hi all
Can someone please delete 'docs-mini/README.plib' in 'next' or all
branches where you need plib = 1.8.4?
Thanks- Yves
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G
21 matches
Mail list logo
