Hello Tetsu,
tetsu wrote:
http://envtech.hp.infoseek.co.jp/737kix/apt_RJBB.dat
[...]
Please anyone tell me how to convert to the FlightGear format?
This already _is_ the format as used by FlightGear - simply remove the
TaxiDraw 'header' (the first _four_ lines) from your airport file and
add
On Wednesday 08 June 2005 10:36 pm, Ampere K. Hardraade wrote:
Perhaps seperating land and water would be the next thing on the agenda?
If this is in regard to the AI ships driving onto land, the AI ships and AI
carrier can accept a flight plan, but the ability to follow the flight plan
has
Waiting for a permanent release which include the Carrier JSB property,
from the original Mathias Froehlich Patch which insert the Hook and
Launchbar Functionalities (it apply on FG 9.8)
I have ( for my personal use ),
rebuild a Patch which can be applied to the last release (today 12 GMT)
of
* Josh Babcock -- Thursday 09 June 2005 05:39:
It looks like rotate animations require an x-m coord for center tags
even though you can get away without y-m or z-m. What's worse, it
not only fails silently, it grabs the y-m value for x-m and then
uses the z-m value for y-m. Here comes the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Culp schrieb:
If this is in regard to the AI ships driving onto land, the AI ships and AI
carrier can accept a flight plan, but the ability to follow the flight plan
has not yet been implemented. I won't be hard to do. Once that is done,
Erik Hofman wrote:
Martin Spott wrote:
Wouldn't be there a method to avoid planes floating below the surface ?
I remember having the PC-7 sitting at one end of the runway, rotating
back around a point somewhere behind the main gear and disappearing
afterwards. I think this case is coupled to
On June 9, 2005 05:28 pm, Martin Spott wrote:
I'm curious if it is possible to 'simply' define the whole model as a
contact point and let the OpenGL subsystem detect terrain collision.
This would require some return channel from the OpenGL system back
to the application and I have no idea if
Ampere,
It's interesting that you should bring up this subject since the
electrical system is something I've been beating my head on this week.
Let me share my thoughts (which go in a bit of a different direction
from yours.)
1. The current electrical system is data driven rather than
* Curtis L. Olson -- Thursday 09 June 2005 19:52:
4b. [...] But is there a way to have a default nasal function that
can be overwritten by an aircraft specific function?
Sure. AFAIK, every nasal context can write into any nasal namespace.
This does include to overwrite an existing function
Martin Spott wrote:
I'm curious if it is possible to 'simply' define the whole model as a
contact point and let the OpenGL subsystem detect terrain collision.
Not meaningfully. The 3D geometry can tell you collision points
between polygons. It can't tell you whether those polygons are
landing
Melchior FRANZ wrote:
Sure. AFAIK, every nasal context can write into any nasal namespace.
This does include to overwrite an existing function there. I for one
am overwriting view.stepView() from my personal
$FG_ROOT/Nasal/local.nas. I've redefined controls.throttleAxis() to
grab the
OK, this works great: (other than the fact that it doesn't actually do
anything yet)
gearLightCheck = func {
for (i=0; i3; i=i+1) {
thisProp = /gear/gear[ ~ i ~ ]/position-norm;
if ( getprop(thisProp) == 1 ) {
print(green);
} elsif ( getprop(thisProp) == 0
Josh Babcock wrote:
OK, this works great: (other than the fact that it doesn't actually do
anything yet)
if ( getprop(thisProp) == 1 ) {
but this
} elsif ( getprop(thisProp) 1 ) { Line 143
produces this error:
Nasal runtime error: nil used in numeric context
Josh Babcock wrote:
OK, this works great: (other than the fact that it doesn't actually do
anything yet)
gearLightCheck = func {
for (i=0; i3; i=i+1) {
thisProp = /gear/gear[ ~ i ~ ]/position-norm;
if ( getprop(thisProp) == 1 ) {
print(green);
}
I know this is an incredibly dumb question.. but in Nasal an elseif
conditon is expressed as elsif?
- Original Message -
From: Josh Babcock [EMAIL PROTECTED]
To: FlightGear developers discussions flightgear-devel@flightgear.org
Sent: Thursday, June 09, 2005 3:59 PM
Subject:
[EMAIL PROTECTED] wrote:
I know this is an incredibly dumb question.. but in Nasal an
elseif conditon is expressed as elsif?
Perl uses elsif like Nasal. C and derivatives (and Javascript) use
else if only because they hack their parser grammers to handle the
inherent ambiguity. The bourne
Nevermind. I found the Nasal docs.
- Original Message -
From: [EMAIL PROTECTED]
To: FlightGear developers discussions flightgear-devel@flightgear.org
Sent: Thursday, June 09, 2005 4:26 PM
Subject: Re: [Flightgear-devel] NASAL error
I know this is an incredibly dumb question.. but in
Just checked in a JSBSim.hxx and JSBSim.cxx to JSBSim CVS that makes crash
handling user-configurable. The default behavior is the current
subterranean flying behavior. If the user sets the property
/sim/pause-on-crash to true, then the sim will pause on crash, which is the
same behavior
From: Ampere K. Hardraade [EMAIL PROTECTED]
Why should the electrical system be made generic?
It shouldn't. There is a whole class of physical systems that
act as a network with two valued paths. Voltage/Current,
Pressure/Velocity, Density/Massflow, some aerodynamics, etc etc.
All of these
19 matches
Mail list logo
