syd wrote:
Hi Steve ...I found the file in Aircraft/c172/c172-electrical.nas
It works the way I wanted 0 volts at the outputs when the switch
is off.
This should also model battery discharge and charge ... I'm not sure if
we have a battery voltage or ammeter gauge in the default c172,
Hi Steve ...I found the file in Aircraft/c172/c172-electrical.nas
It works the way I wanted 0 volts at the outputs when the switch is
off.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Andy Ross wrote:
Erik pinged me on the Nasal endianness bug, which I *think* has been
fixed. It no longer occurs with the Mac test code I have, but I
didn't find a smoking gun and can't run FlightGear on that mac (shell
access only).
Anyway, please update both (!) SimGear and FlightGear CVS
Erik pinged me on the Nasal endianness bug, which I *think* has been
fixed. It no longer occurs with the Mac test code I have, but I
didn't find a smoking gun and can't run FlightGear on that mac (shell
access only).
Anyway, please update both (!) SimGear and FlightGear CVS sources and
let me
On September 20, 2005 05:15 pm, Andy Ross wrote:
Ampere: there is one incompatible change here. The strc() function
has been removed in favor of the array syntax for addressing bytes
out of a string. The A380 scripts are the only code that uses it, so
I didn't bother including a
On Donnerstag 11 August 2005 10:09, Erik Hofman wrote:
Mathias Fröhlich wrote:
I have sometimes strange problems with some keybindings.
I do not know if these are dony by nasal or if the ones in question are
implementented directly.
But sounds like that.
I expect so. About every key I
Mathias Fröhlich wrote:
You use gcc-4.* on your O2?
No the O2 is big-endian, different problem.
I thought that you use sgi's CC?
Yes.
Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Andy Ross wrote:
* Yes, I'm using Nasal at work. We even have a mac here that has
reproduced the endianness issues, so hopefully I'll have a fix for
that ready in a few days.
Yes! ;-)
Seriously, it's probably a *lot* faster to hunt down the problem in a
stand-alone version of Nasal.
Just in case anyone else has noticed: I discovered today at work* that
the gcc 4.0.1 shipped with Fedora Core 4 miscompiles Nasal pretty
badly when the optimizer is turned on.
I'm not sure what the effect will be on FlightGear specifically, as I
haven't had time to do a build recently.
This is just an update/reminder concerning Nasal errors on IRIX.
This is the startup log of a current FG-Build. At the end I press 'v'
once to change the view - which obviously doesn't work. Pressing F10 to
enable the menu is still functional:
SGTimeZoneContainer(): No such file or directory
Martin Spott wrote:
Andy Ross wrote:
If someone can set me up with ssh access to a shell account (no need
to run the whole fgfs binary) on a Mac or SGI or whatnot, let me
know. :)
I could offer an account on an UltraSparc with GCC,
As long as the compiler generates 32 bit executables
Hi,
I've tried several approaches to get Nasal working for big-endian
(32-bit) systems but they all fail. I don't see a way to get this
working and this makes FlightGear unusable for IRIX at least:
Nasal runtime error: non-objects have no members
at
Erik Hofman wrote:
I've tried several approaches to get Nasal working for big-endian
(32-bit) systems but they all fail. I don't see a way to get this
working and this makes FlightGear unusable for IRIX at least:
Man, am I happy that I'm not the only one with disabled throttle on
IRIX :-)
Martin Spott wrote:
Erik Hofman wrote:
I've tried several approaches to get Nasal working for big-endian
(32-bit) systems but they all fail. I don't see a way to get this
working and this makes FlightGear unusable for IRIX at least:
Man, am I happy that I'm not the only one with disabled
Andy Ross wrote:
Hrm. I kinda assumed when the reports stopped that this was just a
symptom of a version skew or unsynchronized checkout. :(
I was waiting for a faster CPU to arrive which should speedup testing,
but it takes longer than I had anticipated.
Try this: hard-code the
Andy Ross wrote:
Martin Spott wrote:
Man, am I happy that I'm not the only one with disabled throttle on
IRIX :-)
Hrm. I kinda assumed when the reports stopped that this was just a
symptom of a version skew or unsynchronized checkout. :(
I tried to investigate the problem but failed to
Do you have a ref for a function definition for NASAL's settimer() please?
I am working on a red_headed_stepchild_of_a_hard_to_work_with_joystick.xml
that might require it also :-)
- Original Message -
From: Josh Babcock [EMAIL PROTECTED]
To: FlightGear developers discussions
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);
}
: [Flightgear-devel] NASAL error
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
[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
Josh Babcock wrote
Andy Ross wrote:
Josh Babcock wrote:
Is there a way to tell YASim to add or subtract some drag? I
want to add some drag to the superfort when the bomb doors
open. They were supposed to really wreck the airflow, though
not as bad as the lg which doubled the drag!
Is there a way to tell YASim to add or subtract some drag? I want to add
some drag to the superfort when the bomb doors open. They were supposed
to really wreck the airflow, though not as bad as the lg which doubled
the drag!
Josh
___
Flightgear-devel
Josh Babcock wrote:
Is there a way to tell YASim to add or subtract some drag? I
want to add some drag to the superfort when the bomb doors
open. They were supposed to really wreck the airflow, though
not as bad as the lg which doubled the drag!
Well, right now you could model them as landing
Josh Babcock wrote:
I don't think the LG thing will work, they have to be extended
independently of the LG.
Just tie a different property to the EXTEND input on the gear.
Nothing in YASim is hardcoded; all user inputs are configurable.
Speedbrakes would be great, though I would request that
More not-quite-FlightGear subject matter ahead. But I need advice:
Nasal needs a character constant syntax. That is, the ability to
write an ASCII charactrer as a numerical constant. In C/C++, you use
single quotes to do this (e.g. the token 'A' is just a synonym for the
integer value 65).
Andy Ross wrote:
More not-quite-FlightGear subject matter ahead. But I need advice:
Nasal needs a character constant syntax. That is, the ability to
write an ASCII charactrer as a numerical constant. In C/C++, you use
single quotes to do this (e.g. the token 'A' is just a synonym for the
Andy Ross wrote
So anyway, which of the following are good/bad choices for a character
constant syntax:
`A` @A $A %A A @A $A %A A cA
Anything but `A` - I'm bound to misread that in the future sometime. I
favour a function.
Regards,
Vivian
From: Andy Ross
snip
Perl and Python get away without having character constants at all.
They do string indexing by making substrings at runtime. But
substrings are garbage-collected, which makes them a little expensive.
I don't want to thrash the heap just to iterate through a single
Erik Hofman wrote:
At first I was thinking using #'A' since # represents a number
already in most cases, but then again; how about just using a
new function?
Just to be clear, there is a function to do this already: strc()
returns the value of the Nth byte in a string. The index
defaults to
-devel] Nasal
Roy Vegard Ovesen wrote:
On Thursday 18 November 2004 16:53, Vance Souders wrote:
Here's a snippet of code to convert the inhg property value to mbar and
then use this to rotate the left-most digit on the mbar display. The
code
doesn't seem to work; Is this the correct usage
Vance Souders wrote:
Nope, it doesn't work. The interpolation table doesn't seem to handle the
small values necessary for texture translation. For instance, you would
think an input value of 29.90 into the following table would give you an
output value of 0. No dice. You get .9 no
On Thursday 18 November 2004 01:33, Boris Koenig wrote:
sure, right - but putting nasal scripts into module tags like in other
PropertyList encoded XML files isn't yet supported natively.
Also, I don't think Vance wanted to link the Nasal script to a
particular action ?
I don't want to
Roy Vegard Ovesen wrote:
On Thursday 18 November 2004 01:33, Boris Koenig wrote:
sure, right - but putting nasal scripts into module tags like in other
PropertyList encoded XML files isn't yet supported natively.
Also, I don't think Vance wanted to link the Nasal script to a
particular action ?
I
: [Flightgear-devel] Nasal
On Thursday 18 November 2004 01:33, Boris Koenig wrote:
sure, right - but putting nasal scripts into module tags like in other
PropertyList encoded XML files isn't yet supported natively.
Also, I don't think Vance wanted to link the Nasal script to a
particular action
PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Boris Koenig
Sent: Thursday, November 18, 2004 8:27 AM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Nasal
Roy Vegard Ovesen wrote:
On Thursday 18 November 2004 01:33, Boris Koenig wrote:
sure, right - but putting nasal scripts
Roy Vegard Ovesen wrote:
On Thursday 18 November 2004 16:53, Vance Souders wrote:
I wish I had a clue about how to add text chunks to the 3d animation code :-|
What exactly do you want to do ?
Do you want to animate text ?
If you only want to add text layers, then there are numerous examples in
Roy Vegard Ovesen wrote:
On Thursday 18 November 2004 16:53, Vance Souders wrote:
Here's a snippet of code to convert the inhg property value to mbar and
then use this to rotate the left-most digit on the mbar display. The
code
doesn't seem to work; Is this the correct usage of the
are welcome.
Thanks,
Vance
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Boris Koenig
Sent: Thursday, November 18, 2004 11:59 AM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Nasal
Roy Vegard Ovesen wrote:
On Thursday 18 November 2004
Ampere K. Hardraade wrote:
On November 16, 2004 09:56 pm, Curtis L. Olson wrote:
Andy Ross wrote:
Sure:
http://plausible.org/nasal/flightgear.html
This should probably move to the FlightGear site, I suppose.
Ahhh, thanks for the url ... it's been too long since the last time I
looked at nasal. I
I'm working on a new cockpit for the T6; the T6's
altimeter displays barometric pressure in both inches HG and MB. I want to add
a small amount of script that converts from the HG reading in the property tree
to MB for the gauge (I need this for the texture translation). After looking
at
Vance Souders wrote:
I'm working on a new cockpit for the T6; the T6's altimeter displays
barometric pressure in both inches HG and MB. I want to add a small
amount of script that converts from the HG reading in the property tree
to MB for the gauge (I need this for the texture translation).
On Thursday 18 November 2004 00:06, Vance Souders wrote:
I'm working on a new cockpit for the T6; the T6's altimeter displays
barometric pressure in both inches HG and MB. I want to add a small amount
of script that converts from the HG reading in the property tree to MB for
the gauge (I need
Is there any documentation that explains how the nasal scripting system
is integrated into FlightGear? I looked a bit, and can't find anything.
If I decide I want to call a nasal script from someplace in the code,
how do I go about doing that? Do I create an entirely new parser and
call it?
Curtis L. Olson wrote:
Is there any documentation that explains how the nasal scripting
system is integrated into FlightGear? I looked a bit, and can't
find anything.
Sure:
http://plausible.org/nasal/flightgear.html
This should probably move to the FlightGear site, I suppose.
If I
Andy Ross wrote:
Curtis L. Olson wrote:
Is there any documentation that explains how the nasal scripting
system is integrated into FlightGear? I looked a bit, and can't
find anything.
Sure:
http://plausible.org/nasal/flightgear.html
This should probably move to the FlightGear site, I suppose.
Andy Ross wrote:
Sure:
http://plausible.org/nasal/flightgear.html
This should probably move to the FlightGear site, I suppose.
Ahhh, thanks for the url ... it's been too long since the last time I
looked at nasal. I can copy it into the source/docs-mini/ directory.
This is pretty much
On November 16, 2004 09:56 pm, Curtis L. Olson wrote:
Andy Ross wrote:
Sure:
http://plausible.org/nasal/flightgear.html
This should probably move to the FlightGear site, I suppose.
Ahhh, thanks for the url ... it's been too long since the last time I
looked at nasal. I can copy it
Hi Andy !
Thanks for answering my Nasal inquiry several weeks ago,
regardless of your vacation - Hope you've had a good
time in Japan ;-)
Andy Ross wrote:
I'm honestly looking for something to get me back into FlightGear
development. I can do the YASim integration if you guys have an
interface
I have hit a snag while writing some Nasal script for the Spitfire model:
I put this in the spitfireIIa-set.xml file
controls
engines
engine n=0
magneto-switch type=bool1/magneto-switch
magneto-switch type=bool1/magneto-switch
/engine
/engines
Vivian Meazza wrote:
I have hit a snag while writing some Nasal script for the Spitfire model:
I put this in the spitfireIIa-set.xml file
controls
engines
engine n=0
magneto-switch type=bool1/magneto-switch
magneto-switch type=bool1/magneto-switch
/engine
Curtis L. Olson wrote:
Vivian Meazza wrote:
I have hit a snag while writing some Nasal script for the Spitfire model:
I put this in the spitfireIIa-set.xml file
controls enginesengine n=0
magneto-switch type=bool1/magneto-switch
magneto-switch
Josh Babcock wrote:
Curtis L. Olson wrote:
Vivian Meazza wrote:
I have hit a snag while writing some Nasal script for the Spitfire
model:
I put this in the spitfireIIa-set.xml file
controls enginesengine n=0
magneto-switch type=bool1/magneto-switch
magneto-switch
Curtis L. Olson
Josh Babcock wrote:
Curtis L. Olson wrote:
Vivian Meazza wrote:
I have hit a snag while writing some Nasal script for the Spitfire
model:
I put this in the spitfireIIa-set.xml file
controls enginesengine n=0
magneto-switch
Vivian Meazza wrote:
Curtis L. Olson wrote:
Right, but the aircraft I have seen have just one *switch* ... off,
both, left, right (and sometimes starter power is rolled in too.)
If the physical aircraft has a separate switch for each magneto, then
the underlying logic should just change
Vivian Meazza wrote:
This works:
setprop(controls/engines/engine/magneto-switch[0],1);
But this doesn't:
setprop(controls/engines/engine/magneto-switch[1],1);
I can work around it no problem, but I think that it should work. I
can see,
but can't access ../magneto-switch[1] in the Browse
Andy Ross wrote:
Actually, it might be cleaneast to model the engine control properties
as something like:
/engines/engine[n]/magneto[0] (boolean)
/engines/engine[n]/magneto[1] (boolean)
/engines/engine[n]/starter(boolean)
And re-write the standard switch binding such that it sets the
Andy Ross wrote
Sent: 17 June 2004 19:36
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Nasal - Question
Vivian Meazza wrote:
Curtis L. Olson wrote:
Right, but the aircraft I have seen have just one
*switch* ... off,
both, left, right (and sometimes
Andy Ross advised
Sent: 17 June 2004 19:32
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Nasal - Question
Vivian Meazza wrote:
This works:
setprop(controls/engines/engine/magneto-switch[0],1);
But this doesn't:
setprop(controls/engines/engine/magneto
On Thursday 29 April 2004 23:19, Andy Ross wrote:
This is a perfectly legal script, for example:
nasal
B52F
script![CDATA[
myFunction = func { print(Executing myFunction()!); }
print(Hello World!\n);
]]/script
/B52F
/nasal
When you start up, it
Roy Vegard Ovesen wrote:
I tried this inside an instrument config file, but it didn't work.
It doesn't. The nasal code is read only from under the /nasal/*
subtree of the global properties. Instruments live farther down.
Would it be possible to implement the ability to include nasal
code in
Jim Wilson wrote:
The nasal script doesn't work on the keyboard binding for the c
key (99). I can't see any problem, and there apparently are not any
useful debugging methods for nasal scripts
Have you tried print? It goes out via the standard SG_LOG channel as
an alert. It's true that
Andy Ross wrote:
Jim Wilson wrote:
if (property) {
}
Does not work if the property type is undefined.
I'm a little confused. Is property completely unset (which should
cause a symbol lookup failure), or does if have a value of nil (which
should have a boolean value of false)?
Never
Andy Ross said:
Jim Wilson wrote:
The nasal script doesn't work on the keyboard binding for the c
key (99). I can't see any problem, and there apparently are not any
useful debugging methods for nasal scripts
Have you tried print? It goes out via the standard SG_LOG channel as
an
I want the 737's heading bug to be set to the aircraft's current magnetic
heading at startup. I put a nasal script in 737-jsbsim-set.xml like this:
nasal
SetHeadingBug
script
setprop(/autopilot/settings/heading-bug-deg,
getprop(/orientation/heading-magnetic-deg));
/script
David Culp wrote:
The problem is that the script is executed while the aircraft's
heading is still zero, prior to it being oriented with the runway. Is
there a way to have the script execute only after the aircraft is
aligned with the runway?
As an immediate hack, you can set it up to run
settimer(func { setprop(SRCPROP, getprop(DSTPROP)) }, DELAY);
Thanks Andy, six seconds works well for me, which seems like a lot. I wonder
how much variation there is among users. It would be nice if we had a
standard nasal script, init-complete.nas, that is called after everything
else
Gene Buckle wrote:
Andy, is it possible to make socket calls within a Nasal script? If
not, how hard would it be to add that kind of ability?
Right now, you can only talk to the rest of FlightGear through the
properties tree. Adding the socket stuff probably wouldn't be hard at
all; what do
Gene Buckle wrote:
Andy, is it possible to make socket calls within a Nasal script? If
not, how hard would it be to add that kind of ability?
Right now, you can only talk to the rest of FlightGear through the
properties tree. Adding the socket stuff probably wouldn't be hard at
all;
Is there a way to assign an instantaneous joystick button, but not have
the value jump directly from one value to another? Currently I have the
following code in my joystick file but it results in the brakes snapping
on and off. I wanted to get a smoother transition to be more realistic
in
Josh Babcock wrote:
I tried propertySlew() but it seems that the value wasn't going to
the numbers I supplied, but only slewing for a very short period of
time taht wasn't even consistant.
You need to mark the bindings repeatable. See the trim bindings for
examples.
The propertySlew()
Andy Ross wrote:
SNIP
You need to mark the bindings repeatable. See the trim bindings for
examples.
Whoops. Typo, or cut-and-past-o I guess. That's what you get for coding
with the flu I. Now the brakes go on like I want, but I have the same
problem with them coming off. Apparently
Never mind. I just remembered interpolate. This works perfectly.
Josh
button n=1
descLeft Brake/desc
repeatable type=booltrue/repeatable
binding
commandnasal/command
scriptinterpolate(/controls/gear/brake-left,
props.globals.getNode(/controls/gear/brake-left).getValue(), 0, 1,
0.1)/script
Some quick suggestions:
You wrote:
interpolate(/controls/gear/brake-left,
props.globals.getNode(/controls/gear/brake-left).getValue(),
0, 1, 0.1)
Actually, the implementation of interpolate() always starts from the
current value of a property, so in fact there's no
I just commited Nasal bindings for my Saitek X45. I'll get to the rest
soon, but this one is there as a working example if anyone wants to try
porting the bindings for their own stick. It should be mostly
self-explanatory.
Andy
___
Flightgear-devel
On Tue, 23 Dec 2003, Andy Ross wrote:
I just commited Nasal bindings for my Saitek X45. I'll get to the rest
soon, but this one is there as a working example if anyone wants to try
porting the bindings for their own stick. It should be mostly
self-explanatory.
I'd love to add another
I finally found the Nasal memory corruption bug this morning. I was
right that it was triggered by garbage collection, but it wasn't in
the Nasal code. The FGBinding implementation was holding a
SGPropertyNode* and assuming that its callees would never try to use
the SGPropertyNode_ptr interface
Andy,
What method would you recommend for a script that basically has to run
forever.
What I'm trying to do is add continuous motion to the sailship by
interpolating between +10 and -10 degrees pitch, but I haven't found a
clue on how to do this with Nasal.
Any ideas?
Erik
Andy Ross wrote:
Erik Hofman wrote:
What method would you recommend for a script that basically has to run
forever.
What I'm trying to do is add continuous motion to the sailship by
interpolating between +10 and -10 degrees pitch, but I haven't found a
clue on how to do this with Nasal.
Erik Hofman wrote:
I tried this with a linear interpolation table but I think a problem
right now is the fact that the timer is frame rate dependent. And
since I'm running at a frame rate of about 5 frames per second this
can be a problem.
The interpolator is realtime (er, simtime) based;
Another update is available at:
http://www.plausible.org/andy/fg-nasal-1.5.tar.gz
This contains all the new features from yesterday, plus the ability to
load code from the /nasal subtree of the global properties at
initialization time. Basically, you can now do:
nasal
c172
I promised Curt earlier today that I would write up some integration
documentation for Nasal. There is a draft available at:
http://www.plausible.org/andy/fg-nasal.html
This isn't documentation for the language itself. That requirement is
covered (albeit poorly) by some pages and sample code
OK, I had some time over the weekend to carry out my threat of hacking
the Nasal interpreter into FlightGear. So now we have another
language to flame about. :)
http://www.plausible.org/andy/fg-nasal-1.0.tar.gz
[This touches SimGear, FlightGear and the base package, so you'll
see
I just want to know: why nasal?
:-)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Jon S. Bertdt wrote:
I just want to know: why nasal?
Because, sir, I am a marketing genius. :)
Actually, it start out life as Nasl, which was an acronym for Not
Another Scripting Language. There wasn't much purpose behind that
name either, but it was reasonably descriptive. And similar
Jon S. Berndt wrote:
I just want to know: why nasal?
Like I said. I don't have a clue.
Andy
nasal ... Sounds like it might have something to do with the space program
... ;-)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
88 matches
Mail list logo
