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 thes
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
Nevermind. I found the Nasal docs.
- Original Message -
From: <[EMAIL PROTECTED]>
To: "FlightGear developers discussions"
Sent: Thursday, June 09, 2005 4:26 PM
Subject: Re: [Flightgear-devel] NASAL error
I know this is an incredibly dumb question.. but in Nasal an "elseif"
conditon
[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 b
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"
Sent: Thursday, June 09, 2005 3:59 PM
Subject: [Flightgear-devel] NASAL error
Josh Babcock wrote:
> OK, this works great: (other than the fact that it doesn't actually do
> anything yet)
>
> gearLightCheck = func {
> for (i=0; i<3; i=i+1) {
> thisProp = "/gear/gear[" ~ i ~ "]/position-norm";
> if ( getprop(thisProp) == 1 ) {
> print("green");
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 c
OK, this works great: (other than the fact that it doesn't actually do
anything yet)
gearLightCheck = func {
for (i=0; i<3; i=i+1) {
thisProp = "/gear/gear[" ~ i ~ "]/position-norm";
if ( getprop(thisProp) == 1 ) {
print("green");
} elsif ( getprop(thisProp)
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 joy
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
land
* 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
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 har
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
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 co
A propsal regarding the generalization of aircraft systems
Abstract:
Currently, the electrical system seems to be the only system that can be
configured by the user. Other systems are either fully hardcoded into
Flightgear, or have yet to be modelled. Since dedication to code that
simulates
-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,
* Josh Babcock -- Thursday 09 June 2005 05:39:
> It looks like rotate animations require an coord for tags
> even though you can get away without or . What's worse, it
> not only fails silently, it grabs the value for and then
> uses the value for . Here comes the code.
That's apparently by
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 /
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 no
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
20 matches
Mail list logo
