I've just tried out the c310 @KSFO, current metar conditions.
The Yasim one develops 38PSI of manifold pressure, ~2700RPM
at props and throttle full forward on the ground, brakes applied.
The JSBsim gives a (more realistic-?) 29PSI. No surprise the ground
roll at the Yasim one's is much shorter.
I've just tried out the c310 @KSFO, current metar conditions.
The Yasim one develops 38PSI of manifold pressure, ~2700RPM
at props and throttle full forward on the ground, brakes applied.
The JSBsim gives a (more realistic-?) 29PSI. No surprise the ground
roll at the Yasim one's is much
If this is just flipping the sign why not just grep and fix all the aircraft in
CVS that specify incidence? I guess I don't understand the ritual. Maybe
there was more to this change that I'm just not aware of?
Best,
Jim
___
Flightgear-devel
Jim Wilson wrote:
If this is just flipping the sign why not just grep and fix all the aircraft in
CVS that specify incidence? I guess I don't understand the ritual. Maybe
there was more to this change that I'm just not aware of?
Most modelers (if not all) were unaware of this problem. Some
On Sat, 3 Dec 2005, Erik Hofman wrote:
Jim Wilson wrote:
If this is just flipping the sign why not just grep and fix all the
aircraft in CVS that specify incidence? I guess I don't understand the
ritual. Maybe there was more to this change that I'm just not aware of?
Most modelers (if not
Jim Wilson wrote:
If this is just flipping the sign why not just grep and fix all the aircraft in
CVS that specify incidence? I guess I don't understand the ritual. Maybe
there was more to this change that I'm just not aware of?
The big issue is that developers were actually specifying
Jim Wilwon wrote:
If this is just flipping the sign why not just grep and fix all
the aircraft in CVS that specify incidence?
The files in CVS (most of them -- the ones that weren't pre-fixed
for the 0.9.9 release) specify incidence as documented, not as it
was actually implemented in code. So
Joacim Persson wrote:
I've discovered a difference between how fgfs calls the yasim solver, and
how the yasim binary (aka yasim-test) does it. I have a -yasim.xml which
doesn't pass yasim(-test) but which fgfs accepts... ?:-P
So what is the difference? Number of iterations?
That sounds like
From: Erik Hofman
Jim Wilson wrote:
If this is just flipping the sign why not just grep and fix all the
aircraft in CVS that specify incidence? I guess I don't
understand the ritual. Maybe there was more to this change that I'm just not
aware of?
Most modelers (if not all) were
From: Andy Ross
unintended consequences. The old files were tuned for a broken
implementation, and may need some re-tuning for the fixed one.
Ah ok. I thought it was just an inverted sign on the configuration input.
Best,
Jim
___
On Sat, 3 Dec 2005, Andy Ross wrote:
That sounds like a bug. They are intended to produce identical
behavior. Is it possible you have a yasim binary build from a
different version of the code than your fgfs?
My first thought too.
The file I used was the AN-225-yasim.xml with the only
I've discovered a difference between how fgfs calls the yasim solver, and
how the yasim binary (aka yasim-test) does it. I have a -yasim.xml which
doesn't pass yasim(-test) but which fgfs accepts... ?:-P
So what is the difference? Number of iterations?
On Samstag 03 Dezember 2005 01:57, Joacim Persson wrote:
I've discovered a difference between how fgfs calls the yasim solver, and
how the yasim binary (aka yasim-test) does it. I have a -yasim.xml which
doesn't pass yasim(-test) but which fgfs accepts... ?:-P
So what is the difference?
I've been short of time recently, but Curt is keen on getting the
twist/incidence fix into YASim in time for the next release. So I've
committed it more or less blind. :)
A quick grep through the source code gives a list of affected aircraft
configurations that I've attached below. The fix is
On Thursday 01 Dec 2005 21:08, Andy Ross wrote:
I've been short of time recently, but Curt is keen on getting
the twist/incidence fix into YASim in time for the next
release. So I've committed it more or less blind. :)
A quick grep through the source code gives a list of affected
aircraft
On Thu, 1 Dec 2005, Andy Ross wrote:
AN-225/AN-225-yasim.xml
The patched Yasim spitted it out again.
No twist set in that file, only incidence (4° positive).___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
On Sunday 24 Jul 2005 00:31, [EMAIL PROTECTED] wrote:
hello all.
this is my first post to this mailing list. (some people might
know me from the irc channel, which i joined about a week ago
for the first time, not counting a brief visit a year ago.) i
have been following the development of
Some time ago I wrote:
Andy Ross:
If you do mean this equation then I can certainly live with that. If
not, I'll need to put my thinking cap on ... I've updated the
graphical representation here:
Remind me again which one of these is the real engine data, and what
the source
Is there any king of piston engine temp modeling going on in YASim yet?
I see egt-degf but it looks like it's just the air temp.
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Josh Babcock wrote:
Is there any king of piston engine temp modeling going on in YASim
yet? I see egt-degf but it looks like it's just the air temp.
No. There are actually many spots on engines where people like to
stick thermocouples. Oil temperature and cylinder head temperature
are the
Andy Ross wrote
Drew wrote:
IMHO, it's best to use interpolation tables rather than equations if
you're trying to curve fit empirical data.
Not in this context. The data here isn't being used to model a
specific engine, but to provide sane parameters for all
(super/turbochared)
On Sat, 23 Apr 2005 10:15:31 +0100, Vivian wrote in message
[EMAIL PROTECTED]:
Andy Ross wrote
Drew wrote:
IMHO, it's best to use interpolation tables rather than equations
if you're trying to curve fit empirical data.
Not in this context. The data here isn't being used to
Arnt Karlsen wrote:
Andy Ross wrote
Drew wrote:
IMHO, it's best to use interpolation tables rather than equations
if you're trying to curve fit empirical data.
Not in this context. The data here isn't being used to model a
specific engine, but to provide sane
On Sat, 23 Apr 2005 20:02:48 +0100, Vivian wrote in message
[EMAIL PROTECTED]:
Arnt Karlsen wrote:
Andy Ross wrote
Drew wrote:
IMHO, it's best to use interpolation tables rather than
equations if you're trying to curve fit empirical data.
Not in this
-Original Message-
From: [EMAIL PROTECTED] [mailto:flightgear-devel-
[EMAIL PROTECTED] On Behalf Of Arnt Karlsen
Sent: 23 April 2005 22:02
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] YASim turbo/supercharger issues
On Sat, 23 Apr 2005 20:02:48 +0100
Selon Andy Ross [EMAIL PROTECTED]:
(-0.25 * math::pow(rpm_norm,3)) + (-0.15 * math::pow(rpm_norm,2))
+ (1.11 * rpm_norm);
Whereas this one is just really obviously a polynomial, and I
understand polynomials, they're simple and not scary at all:
rpm_norm * (1.11 - rpm_norm * (0.15 *
On Friday 22 April 2005 01:46, Norman Vine wrote:
Andy Ross writes:
Vivian Meazza wrote:
I used the power form because it is easier to read, but if the other
form produces a performance advantage, then of course we must use
it.
It's actually not so much about performance, really.
Andy Ross wrote:
Vivian Meazza wrote:
I used the power form because it is easier to read, but if the other
form produces a performance advantage, then of course we must use
it.
It's actually not so much about performance, really. Readability can
mean different things. The problem is
Vivian Meazza wrote:
y = -0.25x3 + 0.15x2 + 1.11x
Thinking about the over-speed situation overnight, the Merlin was
allowed to go to 3600 rpm for brief periods, and even then damage to
the engine was possible. This is a normalised value of 1.2. The K
Series will go to 9000 (don't try this on
Andy Ross:
If you do mean this equation then I can certainly live with that. If
not, I'll need to put my thinking cap on ... I've updated the
graphical representation here:
Remind me again which one of these is the real engine data, and what
the source is? The only line on this graph
Drew wrote:
IMHO, it's best to use interpolation tables rather than equations if
you're trying to curve fit empirical data.
Not in this context. The data here isn't being used to model a
specific engine, but to provide sane parameters for all
(super/turbochared) engines. The performance and
Andy Ross wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:flightgear-devel-
[EMAIL PROTECTED] On Behalf Of
Sent: 22 April 2005 15:19
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] YASim turbo/supercharger issues
Vivian Meazza wrote:
y = -0.25x3
The real data is series 1, but only up to rpm-normalised = 1. For values
above 1, it's just a continuation by eye of the data.
(See http://www.turbotechnics.com/supercharger/expo.htm Note that max power
is at 6500 rpm, and that the supercharger output is nearly flat at 7000
rpm.)
I
Yeah, that's something that could be a project in itself. There are a few
ways to do
tables that I know of. JSBSim does gridded tables up to three independent
variables. I'd
like to extend that to ungridded tables of n dimensions. Maybe there's an
algorithm
around somewhere for that. I
Probably several. YASim has one for doing interpolation of standard
atmosphere parameters, and I'm sure there's a similar engine in the
JSBSim code, which depends on tables extensively in its configuration.
Yeah, that's something that could be a project in itself. There are a few ways
to do
It's nice to be able to have backout routines for interpolation
tables, as well, which can be extremely helpful in initialization
code. For tables up to 3d with fixed independent indices (is this
what you meant by 'grid', or did you mean fixed intervals?), this is
pretty straightforward.
Vivian Meazza wrote:
The attached diff models the output of a gear-driven
supercharger
I just now got a chance to sit down and puzzle this out. I see where
it's going: instead of ignoring the RPM contribution to boost, it adds
an extra factor that reduces the boost at lower RPMs. It works by
Andy Ross wrote:
Vivian Meazza wrote:
The attached diff models the output of a gear-driven
supercharger
I just now got a chance to sit down and puzzle this out. I see where
it's going: instead of ignoring the RPM contribution to boost, it adds
an extra factor that reduces the boost at
Vivian Meazza wrote:
I used the power form because it is easier to read, but if the other
form produces a performance advantage, then of course we must use
it.
It's actually not so much about performance, really. Readability can
mean different things. The problem is that when I see a
Andy Ross writes:
Vivian Meazza wrote:
I used the power form because it is easier to read, but if the other
form produces a performance advantage, then of course we must use
it.
It's actually not so much about performance, really. Readability can
mean different things. The problem
On Thu, 21 Apr 2005 19:46:10 -0400, Norman wrote in message
[EMAIL PROTECTED]:
Andy Ross writes:
Whereas this one is just really obviously a polynomial, and I
understand polynomials, they're simple and not scary at all:
rpm_norm * (1.11 - rpm_norm * (0.15 * rpm_norm + 0.25))
Hi,
Since one day YASim make use of the groundcache.
That means for aircraft models where the 3d-model animates the gear
compression well (like Vivians seahawk for example), the gears exaclty follow
the slope of the ground.
Also the aircraft carrier hardware is integrated in YASim.
Starting
Mathias Fröhlich
Hi,
Since one day YASim make use of the groundcache.
That means for aircraft models where the 3d-model animates the gear
compression well (like Vivians seahawk for example), the gears exaclty
follow
the slope of the ground.
Also the aircraft carrier hardware is
I wrote:
Mathias Fröhlich
Hi,
Since one day YASim make use of the groundcache.
That means for aircraft models where the 3d-model animates the gear
compression well (like Vivians seahawk for example), the gears exaclty
follow
the slope of the ground.
Also the aircraft
Jim Wilson wrote:
Speaking of which, in the prop config, what exactly do the cruise
numbers do? If I'm not getting enough thrust still out of the prop,
what should I mess with first?
This is the black magic part, and could really use a redesign. The
cruise pitch (the RPM and an airspeed)
Andy Ross said:
Jim Wilson wrote:
Speaking of which, in the prop config, what exactly do the cruise
numbers do? If I'm not getting enough thrust still out of the prop,
what should I mess with first?
This is the black magic part, and could really use a redesign. The
cruise pitch (the
Jim Wilson wrote:
What should I look for then when mucking with the cruise numbers from
the prop definition? Or is there some way to just remove them?
One thing to try would be to remove the variable pitch settings
entirely and nail the prop down at your specified cruise setting
(which should
Andy Ross said:
Jim Wilson wrote:
If you look at that manual the diagram in Section I that shows
the control box, indicates at #12 Prop Control (I've only got
about 6 pages from that manual). That's the blue knob with the
P on it in the model. The control box indicates Max RPM with
Jim Wilson wrote:
The min/max range, does that refer to engine RPM or propellor?
Propeller. It's a setting for the governor. With the newer syntax,
the engine and propeller are separate XML tags, so hopefully it should
be clearer which is which. If an attribute on the propeller tag takes
Andy Ross said:
Jim Wilson wrote:
The min/max range, does that refer to engine RPM or propellor?
Propeller. It's a setting for the governor. With the newer syntax,
the engine and propeller are separate XML tags, so hopefully it should
be clearer which is which. If an attribute on the
Jim Wilson wrote:
But those numbers you gave me seem to be engine RPM numbers. Sorry
for the confusion. The gear ratio is 0.479 and the merlin max rpm
is 3000 rpm.
Ah, I get it. Sorry for the confusion. :)
I guess the gauge in the cockpit shows engine speed, but the YASim
file wants
Jim Wilson wrote
Andy Ross said:
Jim Wilson wrote:
The min/max range, does that refer to engine RPM or propellor?
Propeller. It's a setting for the governor. With the newer syntax,
the engine and propeller are separate XML tags, so hopefully it should
be clearer which is which.
Vivian Meazza wrote:
Yes - perhaps Andy will recall our long discussion of a year ago?
Only vaguely, and I currently lack the time to crawl through the
archives. You keep hinting that you want something done. Can you be
more specific?
Andy
___
Andy Ross
Vivian Meazza wrote:
Yes - perhaps Andy will recall our long discussion of a year ago?
Only vaguely, and I currently lack the time to crawl through the
archives. You keep hinting that you want something done. Can you be
more specific?
Yes - sorry. I redid the Merlin engine
Andy Ross said:
Jim Wilson wrote:
But those numbers you gave me seem to be engine RPM numbers. Sorry
for the confusion. The gear ratio is 0.479 and the merlin max rpm
is 3000 rpm.
Ah, I get it. Sorry for the confusion. :)
I guess the gauge in the cockpit shows engine speed, but
Jim Wilson wrote:
Now I'm finding that we're seeking the engine rpm instead of the
prop-rpm.
Andy Ross wrote:
If an attribute on the propeller tag takes engine RPM, then that
would be a bug.
See? I was exactly right. :)
Can you try the following fix to PropEngine.cpp? That should fix it,
Andy Ross said:
Jim Wilson wrote:
Now I'm finding that we're seeking the engine rpm instead of the
prop-rpm.
Andy Ross wrote:
If an attribute on the propeller tag takes engine RPM, then that
would be a bug.
See? I was exactly right. :)
Can you try the following fix to
Jim Wilson wrote:
Here is my local config for the p51d yasim propeller. Most of these
values are pretty much on target according to actual specifications.
The problem is that it appears to not produce sufficient thrust.
I did actually get started on this at one point. :)
The first problem I
Andy Ross said:
Jim Wilson wrote:
Here is my local config for the p51d yasim propeller. Most of these
values are pretty much on target according to actual specifications.
The problem is that it appears to not produce sufficient thrust.
I did actually get started on this at one point.
Jim Wilson wrote:
So, let's assume you got a good manual. How does this RPM governor
control work? And how can I implement that in YASim?
Just set min-rpm and max-rpm properties to the RPMs in the handbook,
basically. The propeller will automatically modify its pitch to seek
to those values.
Andy Ross said:
Jim Wilson wrote:
So, let's assume you got a good manual. How does this RPM governor
control work? And how can I implement that in YASim?
Just set min-rpm and max-rpm properties to the RPMs in the handbook,
basically. The propeller will automatically modify its pitch
Jim Wilson wrote:
If you look at that manual the diagram in Section I that shows
the control box, indicates at #12 Prop Control (I've only got
about 6 pages from that manual). That's the blue knob with the
P on it in the model. The control box indicates Max RPM with
the blue knob all the way
Here is my local config for the p51d yasim propeller. Most of these values
are pretty much on target according to actual specifications. The problem is
that it appears to not produce sufficient thrust.
Is it possible that we have a flaw in the thrust calculation? Does anyone
have any actual
Jim Wilson wrote:
Here is my local config for the p51d yasim propeller. Most of these
values
are pretty much on target according to actual specifications. The problem
is
that it appears to not produce sufficient thrust.
Is it possible that we have a flaw in the thrust calculation?
Melchior FRANZ wrote:
Here's another problem: $ fgfs --aircraft=c172-610x-jsbsim makes fgfs
abort, because this redirects to ../c172r/c172r-jsbsim-base.xml, which
tries to include c172r-base.xml. But this file is searched in c172/, not
in c172r (where it could be found).
This is fixed in CVS
I'm less successful with the VRP scheme than Jim with the c310u3a. The bo105
looked quite OK all the time, but that's just a coincidence. Actually, there
must be a bug somewhere ... in YASim?
The bo105 yasim config treats the nose 'tip' as the origin. But the 3d model
thinks the main rotor axis
Melchior FRANZ said:
I'm less successful with the VRP scheme than Jim with the c310u3a. The bo105
looked quite OK all the time, but that's just a coincidence. Actually, there
must be a bug somewhere ... in YASim?
The bo105 yasim config treats the nose 'tip' as the origin. But the 3d model
Matthew Law said:
David Megginson wrote:
I cannot reproduce it on my system:
fgfs [EMAIL PROTECTED] --aircraft=j3cub
I put on the parking brake (who'd have thought the J3 Cub had a
parking brake?) and tried moving all of the control surfaces. They
had no effect on the
David Megginson wrote:
I cannot reproduce it on my system:
fgfs [EMAIL PROTECTED] --aircraft=j3cub
I put on the parking brake (who'd have thought the J3 Cub had a
parking brake?) and tried moving all of the control surfaces. They
had no effect on the aircraft, either with the engine on or
David Megginson wrote:
Andy Ross wrote:
Uh... YASim doesn't model wash effects, so there really isn't any
process by which a pure control input would generate force. Are you
sure you weren't just sitting in a stiff wind? Can anyone else
replicate this?
I cannot reproduce it on my system:
fgfs
David Megginson wrote:
That shouldn't be from my change -- can you do it with other YASim
planes?
I see the same issue with elevator on the c172-3d-yasim but not
aileron. Again with the pa28-161 -looks to be about 5-10 deg judging by
the attitude from inside the cockpit...
All the best,
I see the same issue with elevator on the c172-3d-yasim but not
aileron. Again with the pa28-161 -looks to be about 5-10 deg judging by
the attitude from inside the cockpit...
Also, try side slipping any of the cessnas or the pa28. It seems that
in this flight regime the rudder seems to
Matthew Law wrote:
David Megginson wrote:
Matthew Law wrote:
It seems much, much better to me. However, I can sit at minimum
power with the brakes on in nil wind and rock from one main wheel to
the other using the ailerons. I can also lift the tail off the
ground at minimum power.
Andy Ross wrote:
Uh... YASim doesn't model wash effects, so there really isn't any
process by which a pure control input would generate force. Are you
sure you weren't just sitting in a stiff wind? Can anyone else
replicate this?
I cannot reproduce it on my system:
fgfs [EMAIL PROTECTED]
Jim Wilson wrote
Andy Ross said:
Vivian Meazza wrote:
Performance: max = 437mph at combat emergency power at 25000ft,
413mph at 15000ft, 395mph at 5000ft, cruising speed 362mph, climb
rate 3475 ft/min. Service ceiling 41,900ft.
How much is combat emergency power? The
Hi Jim
The other day you were saying about Jon do a
JSBSIM fdm well there is one over at JSBSIM but
I have done a separate one that will drop into
FG if you are interested.If not no problems.
Cheers
Innis
_
Personalise your phone with
-Original Message-
Jim Wilson wrote:
Andy Ross said:
Jim Wilson wrote:
It'd be great if someone else could look at the P51D fdm.
I'm lost.
Flight dynamics is neither my area of expertise or interest. The
only reason I did it in the first place is I had a 3D
model
Hi Jim
The other day you were saying about Jon do a
JSBSIM fdm well there is one over at JSBSIM but
I have done a separate one that will drop into
FG if you are interested.If not no problems.
I was doing one ... still have it in-work. Kept running into things I wanted to fix and
add in the
Hi Jon
Jon Berndt writes
I was doing one ... still have it in-work. Kept running into things I
wanted to fix and
add in the code and getting distracted. I was using DATCOM to help with
aero tables. Now
we are close to having aero tables generated with DATCOM+ directly (thanks
to Bill
Yes I know I downloaded it and used it. Didn't know about the monitoring
file you were outputing from it, ended up with a 400meg file, good thing
I had it on the big drive(LOL).
Oops! :-) I really ought to turn these off by default. In fact, the OUTPUT section is
destined to be removed from
Hi Jon
Jon Berndt writes
What I am most curious about is how easy it was to take off.
Yes pretty good it comes up on to the front wheels after about
200 meters and lifts off at about 120mph with no flap.Dont know
if they used flap on these A/C on t/o. I guess someone here will know.
It is
Vivian Meazza wrote:
Performance: max = 437mph at combat emergency power at 25000ft,
413mph at 15000ft, 395mph at 5000ft, cruising speed 362mph,
climb rate 3475 ft/min. Service ceiling 41,900ft.
How much is combat emergency power? The trick is getting the actual
numbers right, is it possible
On Wed, 19 May 2004 07:06:04 -0700
Andy Ross [EMAIL PROTECTED] wrote:
Vivian Meazza wrote:
Performance: max = 437mph at combat emergency power at 25000ft,
413mph at 15000ft, 395mph at 5000ft, cruising speed 362mph,
climb rate 3475 ft/min. Service ceiling 41,900ft.
I just ordered a copy of the
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Andy Ross
Sent: 19 May 2004 15:06
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] YASim prop changes
Vivian Meazza wrote:
Performance: max = 437mph at combat emergency
Jon S. Berndt wrote:
Please do. It will be interesting to see what kind of relationship
there is between F-15D numbers and P-51D numbers, and how you relate
the two ...
Heh, oops. :)
For folks who didn't get the joke in my typo: the manual I ordered is
a post-war one for the North American
Andy Ross said:
Vivian Meazza wrote:
Performance: max = 437mph at combat emergency power at 25000ft,
413mph at 15000ft, 395mph at 5000ft, cruising speed 362mph,
climb rate 3475 ft/min. Service ceiling 41,900ft.
How much is combat emergency power? The trick is getting the actual
I wrote
Jim Wilson wrote
I can see a difference, but it is still broken. No matter
what the setting, now the engine RPM is either way to high or
way to low.
It'd be great if someone else could look at the P51D fdm.
I'm lost. Flight dynamics is neither my area of
Jim Wilson wrote:
It'd be great if someone else could look at the P51D fdm. I'm
lost. Flight dynamics is neither my area of expertise or
interest. The only reason I did it in the first place is I had a
3D model that Jon supposedly had a JSBsim config for that never
materialized.
In
Andy Ross said:
Jim Wilson wrote:
It'd be great if someone else could look at the P51D fdm. I'm
lost. Flight dynamics is neither my area of expertise or
interest. The only reason I did it in the first place is I had a
3D model that Jon supposedly had a JSBsim config for that never
On Tuesday 18 May 2004 16:45, Jim Wilson wrote:
Andy Ross said:
Jim Wilson wrote:
It'd be great if someone else could look at the P51D fdm. I'm
lost. Flight dynamics is neither my area of expertise or
interest. The only reason I did it in the first place is I had a
3D model that
Lee Elliott wrote:
Production Typhoons could exceed 530 mph in dives, with bombs/RPs, and
Tempests could overhaul V1s. I thought the Sea Fury was even faster,
but I don't have a figure off-hand.
The key words being in dives. The solver values are specified in
level flight. And dives can
Andy Ross said:
Lee Elliott wrote:
Production Typhoons could exceed 530 mph in dives, with bombs/RPs, and
Tempests could overhaul V1s. I thought the Sea Fury was even faster,
but I don't have a figure off-hand.
The key words being in dives. The solver values are specified in
level
With the p51d.xml, in response to the legacy engine warning, I've moved
entries out to the piston-engine tag and added a displacement value. See below.
This is aborting on startup. What am I missing?
Best,
Jim
propeller x=-0.75 y=0 z=0
gear-ration=0.479
radius=1.75
Jim Wilson wrote:
This is aborting on startup. What am I missing?
An abort is an XML parse failure. YASim doesn't catch the exception,
and it percolates up to the top of the call stack and causes an
unhelpful error. I need to fix this.
In this case, though, it's just syntax. Your
Andy Ross said:
Jim Wilson wrote:
This is aborting on startup. What am I missing?
An abort is an XML parse failure. YASim doesn't catch the exception,
and it percolates up to the top of the call stack and causes an
unhelpful error. I need to fix this.
In this case, though, it's just
Is there someone who can tell me about local coordinates and global coordinates.
What is the difference?
Moreover, where is exactly the point in which the collision with the ground
is treated?
I have reported down a piece of code of Yasim\Model.cpp with some questions
attached (****)
//
Is there someone who can tell me about local coordinates and global coordinates.
What is the difference?
I have reported down a piece of code of Yasim\Model.cpp with some questions
attached (****)
// Returns a unit down vector for the ground in out, and the // distance
from the local origin
Marco Gugel wrote:
Is there someone who can tell me about local coordinates and
global coordinates. What is the difference?
Local coordinates are in the aircraft frame (note that this isn't
the same convention that other FDMs use for their airframe
coordinates). Global coordinates are in the
I wrote:
Lee Elliott wrote:
I could do a script that monitors the tank levels and de-selects
them when they're empty but I don't know how to best invoke it.
Actually, it wouldn't be hard to make this the default. We could set
a kill engines if empty flag on the tank for aircraft where we
Hi Andy,
First of all, thanks for your help with the config file.
Now I have another question: I would like to ask you if it is possible to
start from Yasim in order to obtain a ground vehicle dynamic model. My idea
is to develop a truck simulation inside FlightGear and I have thought to
start
1 - 100 of 369 matches
Mail list logo
