Re: [Flightgear-devel] nasal electrical system
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, but those should be live if they exist (or once they get created.) The underlying structure is there for the master switch, battery switch, avionics master, etc. It just needs someone to create the corresponding panel objects. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] nasal electrical system
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 http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal on Mac/Sparc/Irix fixed. Maybe.
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 sources and let me know if I broke anything. The original problem seems to be solved now, but it looks like another one has crept in: Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Aircraft/c172p/kap140.nas, line 1233 called from: /opt/share/FlightGear/data/Aircraft/c172p/kap140.nas, line 1245 called from: /opt/share/FlightGear/data/Aircraft/c172p/kap140.nas, line 1268 Initializing Nasal Electrical System Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Aircraft/c172/c172-electrical.nas, line 29 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/view.nas, line 24 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/gui.nas, line 40 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/autopilot.nas, line 29 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/controls.nas, line 17 Nasal runtime error: non-objects have no members Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Nasal on Mac/Sparc/Irix fixed. Maybe.
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 know if I broke anything.
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 compatibility version. Basically, where
you used to write strc(s, 10), you can just do s[10] now. If you
need something to limp along until you can update the code, we can use
something like this in globals.nas:
strc = func(s, n) { s[n] }
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal on Mac/Sparc/Irix fixed. Maybe.
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 compatibility version. Basically, where
you used to write strc(s, 10), you can just do s[10] now. If you
need something to limp along until you can update the code, we can use
something like this in globals.nas:
strc = func(s, n) { s[n] }
Andy
I am not too excited about going through 3000 lines of code to replace the
strc() function at the moment, although I will look into it.
Thanks for the head's up.
Ampere
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal vs. gcc 4.0.x
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 hit generates a Nasal error on my O2. You use gcc-4.* on your O2? I thought that you use sgi's CC? If you experience the same problems with that CC, there is most propably something in the nasal code which compiles well with gcc-3 by accident. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal vs. gcc 4.0.x
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 http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal vs. gcc 4.0.x
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. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Nasal vs. gcc 4.0.x
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. Nonetheless, I'd suggest that anyone having trouble with FC4 (or gcc4 in general) use gcc 3.2.3 for the time being. This is available in the compat-gcc-32 package for Fedora, and you can tell the configure scripts to use it via: export CC=gcc32 I'd be curious to see if anyone else has had this problem. Andy * 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. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Nasal runtime error
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 Audio initialization failed! Altitude = 49 Temp at alt (C) = 17 Temp sea level (C) = 17.0963 Altitude = 49 Dewpoint at alt (C) = 14 Dewpoint at sea level (C) = 14.0098 Reading xml electrical system model from /home/martin/CVS/FlightGear/data/Aircraft/pc7/pc7-electrical.xml Nasal runtime error: non-objects have no members at /home/martin/CVS/FlightGear/data/Nasal/view.nas, line 24 Nasal runtime error: non-objects have no members at /home/martin/CVS/FlightGear/data/Nasal/gui.nas, line 40 Nasal runtime error: non-objects have no members at /home/martin/CVS/FlightGear/data/Nasal/controls.nas, line 17 Nasal runtime error: non-objects have no members at /home/martin/CVS/FlightGear/data/Nasal/autopilot.nas, line 29 Nasal runtime error: non-objects have no members at /home/martin/CVS/FlightGear/data/Nasal/fuel.nas, line 17 Nasal runtime error: no such member at /input/keyboard/key[118]/binding, line 1 Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal big-endian problem (still)
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 (64 bit works fine already) I'll take it. :) Here's a public key for the .ssh/authorized_keys2 file: ssh-rsa B3NzaC1yc2EBIwAAAIEA4LS3Mn9Xps3uPmqlnt3AI0j0dFTEiXzolDWW6aAZL/oRn2b/nh0zdF3onvxxeVDAc+UvyxETqQGGW9GXOgoJosiQb820RIOXn632bW08ia4Vcq1D7776aN6CzEwO420WxT7d2+OI8iDE2n4vj4cE9OyM5k8wSK0Nbef+QNp78PM= [EMAIL PROTECTED] This shouldn't be too hard to figure out. There are three structure layouts, and two of them work fine. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Nasal big-endian problem (still)
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 /opt/share/FlightGear/data/Nasal/view.nas, line 24 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/gui.nas, line 40 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/autopilot.nas, line 29 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/controls.nas, line 17 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/fuel.nas, line 17 Does anyone have a bright idea here? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal big-endian problem (still)
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. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal big-endian problem (still)
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 throttle on IRIX :-) Hrm. I kinda assumed when the reports stopped that this was just a symptom of a version skew or unsynchronized checkout. :( Try this: hard-code the definition at the top of nasal.h to be *little* endian. This will produce unsafe code*, but it should work. This will tell us that the problem is definitely the endianness handling. * It will be possible to create a special number value that looks like a reference, and therefore cause the interpreter to follow an arbitrary pointer. But the chance of that happening accidentally is 1 in 2^32, so the test should certainly work. I'm a little suspicious, though, because the structure layout code didn't change with these Nasal updates (and because the 64 bit layout works fine on my laptop). I'm wondering if something else is being triggered in the MIPS port. What seems to be happening is that something is clobbering a reference that points to live data, so the garbage collector cleans up the namespace hash incorrectly and you get undefined symbol errors. Almost any kind of memory corruption issue can cause this. Unfortunately I've since switched jobs, and don't have access to a big endian machine to test with any more. 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. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal big-endian problem (still)
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 definition at the top of nasal.h to be *little* endian. This will produce unsafe code*, but it should work. This will tell us that the problem is definitely the endianness handling. Tried that, it gives me the same result (and an additional segmentation fault, twice). * It will be possible to create a special number value that looks like a reference, and therefore cause the interpreter to follow an arbitrary pointer. But the chance of that happening accidentally is 1 in 2^32, so the test should certainly work. I'm a little suspicious, though, because the structure layout code didn't change with these Nasal updates (and because the 64 bit layout works fine on my laptop). I'm wondering if something else is being triggered in the MIPS port. I've checked the CVS tree for changes but the union itself didn't change, only the structs is is referring to. The IRIX compilers are particularly snappy about uninitialized pointers, but since it didn't trigger a segmentation fault in the big-endian test I think we can safely say that's not the problem. What seems to be happening is that something is clobbering a reference that points to live data, so the garbage collector cleans up the namespace hash incorrectly and you get undefined symbol errors. Almost any kind of memory corruption issue can cause this. Unfortunately I've since switched jobs, and don't have access to a big endian machine to test with any more. 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. :) Didn't sourceforge provide shell access to different machines for developers (including at least a Mac)? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal big-endian problem (still)
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 dig further into it because of too little spare time Unfortunately I've since switched jobs, and don't have access to a big endian machine to test with any more. 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, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal Settimer
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 flightgear-devel@flightgear.org Sent: Friday, June 10, 2005 2:34 PM Subject: Re: [Flightgear-devel] timer help eagle monart wrote: are there any references to use time delay in functions. i am trying to delay speedbrake for 1.5 scnds everytime activated or deactivated in larcsim . i tried to use sleep() functions in msvc71 but makes the whole sim sleep:) i am looking for example time delays in fg source and would be happy if anyonepoints... _ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d You could easily do it in NASAL using settimer(). Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[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 ( getprop(thisProp) == 0 ) {
print(off);
} else {
print(red);
}
}
settimer(gearLightCheck, 5);
}
but this
gearLightCheck = func {
for (i=0; i3; i=i+1) {
thisProp = /gear/gear[ ~ i ~ ]/position-norm;
if ( getprop(thisProp) == 1 ) {
print(green);
} elsif ( getprop(thisProp) 1 ) { Line 143
print(red);
} else {
print(off);
}
}
settimer(gearLightCheck, 5);
}
produces this error:
Nasal runtime error: nil used in numeric context
at /usr/local/share/FlightGear/data/Aircraft/b29/b29.nas, line 143
I know these props are set, because I put the following in the set.xml file:
controls
gear
nosewheel-caster type=bool archive=ytrue/nosewheel-caster
antiskid type=bool archive=yfalse/antiskid
gear num=0
position-norm0/position-norm
/gear
gear num=1
position-norm0/position-norm
/gear
gear num=2
position-norm0/position-norm
/gear
gear num=3
position-norm0/position-norm
/gear
/gear
/controls
As an aside, the initial output looks like this:
b29-common.xml initialized
0: red
1: red
2: red
3: red
WARNING: Legacy engine definition in YASim configuration file. Please fix.
WARNING: Legacy engine definition in YASim configuration file. Please fix.
WARNING: Legacy engine definition in YASim configuration file. Please fix.
WARNING: Legacy engine definition in YASim configuration file. Please fix.
0: green
1: green
2: green
3: green
0: green
1: green
2: green
3: green
Any thoughts?
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NASAL error
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
at /usr/local/share/FlightGear/data/Aircraft/b29/b29.nas, line 143
Property initialization rules are complicated. You are creating
proprties with a type of UNDEFINED from an XML file, which are
then being set from within the YASim code using setFloatValue().
Something is producing a nil value when you read it, or perhaps
when it is being converted from a string. In general, you should
always ready to handle the case where a property is not yet
initialized, or is deleted and/or changes type at runtime.
As to why your example fails with but works with ==, that
is correct behavior. The less-than operator is obviously
numeric, and dies if one of the arguments (nil, in this case)
cannot be converted to a number. The equality operator is more
general, and returns false under those circumstances. It is
perfectly legal to compare nil with another object for
equality (e.g. if(list.next == nil) { ... }).
Can you try to pare the example down to something I can run and
reproduce?
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [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; i3; i=i+1) {
thisProp = /gear/gear[ ~ i ~ ]/position-norm;
if ( getprop(thisProp) == 1 ) {
print(green);
} elsif ( getprop(thisProp) == 0 ) {
print(off);
} else {
print(red);
}
}
settimer(gearLightCheck, 5);
}
but this
gearLightCheck = func {
for (i=0; i3; i=i+1) {
thisProp = /gear/gear[ ~ i ~ ]/position-norm;
if ( getprop(thisProp) == 1 ) {
print(green);
} elsif ( getprop(thisProp) 1 ) { Line 143
print(red);
} else {
print(off);
}
}
settimer(gearLightCheck, 5);
}
produces this error:
Nasal runtime error: nil used in numeric context
at /usr/local/share/FlightGear/data/Aircraft/b29/b29.nas, line 143
I know these props are set, because I put the following in the set.xml file:
controls
gear
nosewheel-caster type=bool archive=ytrue/nosewheel-caster
antiskid type=bool archive=yfalse/antiskid
gear num=0
position-norm0/position-norm
/gear
gear num=1
position-norm0/position-norm
/gear
gear num=2
position-norm0/position-norm
/gear
gear num=3
position-norm0/position-norm
/gear
/gear
/controls
As an aside, the initial output looks like this:
b29-common.xml initialized
0: red
1: red
2: red
3: red
WARNING: Legacy engine definition in YASim configuration file. Please fix.
WARNING: Legacy engine definition in YASim configuration file. Please fix.
WARNING: Legacy engine definition in YASim configuration file. Please fix.
WARNING: Legacy engine definition in YASim configuration file. Please fix.
0: green
1: green
2: green
3: green
0: green
1: green
2: green
3: green
Any thoughts?
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Umm, never mind. I was setting /controls/gear/... instead of /gear/...
I had the solution a while ago, just typoed it away. Just a case of
NASAL starting up before YASim gets a chance to create the node.
Mea culpa.
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NASAL error
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: [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 ( getprop(thisProp) == 0 ) {
print(off);
} else {
print(red);
}
}
settimer(gearLightCheck, 5);
}
but this
gearLightCheck = func {
for (i=0; i3; i=i+1) {
thisProp = /gear/gear[ ~ i ~ ]/position-norm;
if ( getprop(thisProp) == 1 ) {
print(green);
} elsif ( getprop(thisProp) 1 ) { Line 143
print(red);
} else {
print(off);
}
}
settimer(gearLightCheck, 5);
}
produces this error:
Nasal runtime error: nil used in numeric context
at /usr/local/share/FlightGear/data/Aircraft/b29/b29.nas, line 143
I know these props are set, because I put the following in the set.xml
file:
controls
gear
nosewheel-caster type=bool archive=ytrue/nosewheel-caster
antiskid type=bool archive=yfalse/antiskid
gear num=0
position-norm0/position-norm
/gear
gear num=1
position-norm0/position-norm
/gear
gear num=2
position-norm0/position-norm
/gear
gear num=3
position-norm0/position-norm
/gear
/gear
/controls
As an aside, the initial output looks like this:
b29-common.xml initialized
0: red
1: red
2: red
3: red
WARNING: Legacy engine definition in YASim configuration file. Please
fix.
WARNING: Legacy engine definition in YASim configuration file. Please
fix.
WARNING: Legacy engine definition in YASim configuration file. Please
fix.
WARNING: Legacy engine definition in YASim configuration file. Please
fix.
0: green
1: green
2: green
3: green
0: green
1: green
2: green
3: green
Any thoughts?
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NASAL error
[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 shell is a little terser and uses elif, at the expense of pronouncing the resulting syntax wrong, a bug that Python inherited. So... what on earth is an elseif? No language designer in their right mind would choose THAT. :) Seriously: if you're looking for obvious standards here, it's going to be a looong search... One picks ones brain damage and moves on. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NASAL error
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 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: [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 ( getprop(thisProp) == 0 ) {
print(off);
} else {
print(red);
}
}
settimer(gearLightCheck, 5);
}
but this
gearLightCheck = func {
for (i=0; i3; i=i+1) {
thisProp = /gear/gear[ ~ i ~ ]/position-norm;
if ( getprop(thisProp) == 1 ) {
print(green);
} elsif ( getprop(thisProp) 1 ) { Line 143
print(red);
} else {
print(off);
}
}
settimer(gearLightCheck, 5);
}
produces this error:
Nasal runtime error: nil used in numeric context
at /usr/local/share/FlightGear/data/Aircraft/b29/b29.nas, line 143
I know these props are set, because I put the following in the set.xml
file:
controls
gear
nosewheel-caster type=bool archive=ytrue/nosewheel-caster
antiskid type=bool archive=yfalse/antiskid
gear num=0
position-norm0/position-norm
/gear
gear num=1
position-norm0/position-norm
/gear
gear num=2
position-norm0/position-norm
/gear
gear num=3
position-norm0/position-norm
/gear
/gear
/controls
As an aside, the initial output looks like this:
b29-common.xml initialized
0: red
1: red
2: red
3: red
WARNING: Legacy engine definition in YASim configuration file. Please
fix.
WARNING: Legacy engine definition in YASim configuration file. Please
fix.
WARNING: Legacy engine definition in YASim configuration file. Please
fix.
WARNING: Legacy engine definition in YASim configuration file. Please
fix.
0: green
1: green
2: green
3: green
0: green
1: green
2: green
3: green
Any thoughts?
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] NASAL update YASim parameters
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! Well, right now you could model them as landing gear, which act like flat plate drag objects with the size of their length (just put the gear contact points somewhere where they can't actually touch the ground). Having a speedbrake subobject was something that was really supposed to have been in the code from the beginning. It's really easy, but I just never got around to it. Give me a bit to, er, remember how the code works and maybe I can get it added. Other aircraft could use it too. See the Spitfire which uses a 'gear' object to model the canopy so that there's additional drag when it's open. There's a hack in the Hunter config file to provide a working speedbrake (aka airbrake for the Brits), using the spare flap object on the tail. Works well enough, but a proper solution would be good. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] NASAL update YASim parameters
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 mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NASAL update YASim parameters
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 gear, which act like flat plate drag objects with the size of their length (just put the gear contact points somewhere where they can't actually touch the ground). Having a speedbrake subobject was something that was really supposed to have been in the code from the beginning. It's really easy, but I just never got around to it. Give me a bit to, er, remember how the code works and maybe I can get it added. Other aircraft could use it too. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NASAL update YASim parameters
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 there be capacity for multiple independent ones, just on the general principal of flexibility. Mais Oui. Just like the gear. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Nasal advice...
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).
(Brief background: I just added the ability to read and write
individual bytes in a string with the [] operator, just like you
can for elements of the vector. Thus the need for character
constants to which to compare those bytes.)
But Nasal can't do that, because it already uses single quotes for
unescaped strings, something that will be really useful in the regular
expression interface I am putting together.
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
string (the lack of the ability to do this really annoys me in perl).
So basically, I can't just emulate C, perl or python here, I need to
invent a new syntax.
One possibility is to use the backquote to do this, so `A` would be a
synonym for 65 in Nasal. This would be nice because I could
re-purpose the lexer for double-quoted strings, and then throw an
error if the resulting string was not a single character (single byte
for now, single UTF8 character in the future). But the backquote is
hard to type, and in some fonts hard to distinguish from a regular
single quote.
Some languages do this by prefixing a single token to the constant
instead of enclosing this in quotes. Examples: Ruby expresses 65 as
?A, where Lisp uses \#A. (Nasal can't use ? because of the ternary ?:
operator, but it might use something like @, %, or , or maybe a
single backquote). This is nice because it's easy to type and easy to
read. But the syntax makes it hard to support the same escapes as a
string, so it wouldn't be natural to write things like @\t for a
tab (syntax highlighting in the emacs nasal mode, for example, freaks
out when it sees the lonely backslash).
Or we could do a combination: prefix a normal string constant with a
special token indicating to the lexer that this is a character
constant. Something like cA or @A for 65, for example. This is
easy to read and type, and natural to implement. But it's different
from other languages, and Nasal is trying really hard to stick to
common, proven, universally-understood features in its design.
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
Finally, should I even have a character constant syntax at all? Note
that there is a potential gotcha with this feature: Nasal is
dynamically typed, so there is nothing incorrect with writing code
like:
for(var i=0; isize(str); i+=1) {
if(str[i] == A) { foundA(); }
}
Except that this code is WRONG. The str[i] expression returns a
number, not a string. You can legally (!) compare it with the string
A, but the result will be false in all cases, even when the number
is 65*. Is this kind of mistake common enough to eliminate the idea
of indexed strings returning numbers?
[* I thought briefly about having strings match numbers when the
string was a single character with the same value, but that
doesn't work. A world where 9 is equal to \t but 9 is not
equal to \t is just too weird to contemplate.]
Anyway, feel free to kibitz. I'd back out the string indexing
feature, but I really, really like it...
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal advice...
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 integer value 65). (Brief background: I just added the ability to read and write individual bytes in a string with the [] operator, just like you can for elements of the vector. Thus the need for character constants to which to compare those bytes.) But Nasal can't do that, because it already uses single quotes for unescaped strings, something that will be really useful in the regular expression interface I am putting together. 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? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Nasal advice...
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 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal advice...
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 string (the lack of the ability to do this really annoys me in perl). So basically, I can't just emulate C, perl or python here, I need to invent a new syntax. You could perhaps extend the w3 named entity syntax which uses as left delimiter and ; as right. So that A; would equal #65; But maybe the ; would be a parsing headache... Best regards, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal advice...
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 zero, so you can write strc(A) to get 65 right now. With the new syntax, you can even write A[0] to do the same. The problem (a minor one, admittedly) is that those are runtime operations that have to generate code. What I really want is the ability to just write the number 65 using some simple key combination involving the character A. :) I think I'm leaning towards back quotes, but I'm still not sure. Using backquotes has always meant something special, and character constants aren't very special... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Nasal
Vivian, The interpolation table did the trick. Thanks for the heads-up. -Vance -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vivian Meazza Sent: Thursday, November 18, 2004 12:07 PM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-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 of the scale tag? I can't find an example of its use for a 3D cockpit. animation typetextranslate/type object-namemb_digit_4/object-name property/instrumentation/altimeter/setting-inhg/property scale33.86/scale factor.0001/factor step1000/step !--scroll20/scroll-- axis x0/x y1/y z0/z /axis /animation Thanks again, Vance Hmmm... I guess that the factor tag does the same for 3d as the scale tag does for 2d, so you should put 33.86 inside the factor tag, and remove the scale tag completely. But I'm not sure about this. I wish I had a clue about how to add text chunks to the 3d animation code :-| Here's another way of doing it: data/Aircraft/Spitfire/Models/boost.xml. The data between the interpolate and /interpolate tags converts inHg to psi and changes the output from absolute to gauge. You need to work out the factors involved by hand though. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Nasal
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 matter what the input value is. So it looks like I'm back to scripting to get this to work for the 3D display. Here's what I want to do: Write a script that adds a node to the property tree that contains the mbar value. I only want the script to run when the T6 Texan II is loaded. From what I've looked at, it seems the best place for the script is under the nasal directory? Sorry for all of the questions, but we're building a high fidelity cockpit for the T6 Texan II and I want to get as much as possible working. -Vance animation typetextranslate/type object-namemb_digit_3/object-name property/instrumentation/altimeter/setting-inhg/property interpolation entry ind29.50/ind dep0.9/dep /entry entry ind29.90/ind dep0.0/dep /entry /interpolation !--factor0.001/factor-- step100/step ^ What's this??? !--scroll20/scroll-- axis x0/x y1/y z0/z /axis /animation You may need to try more entries in the interpolation table to make sure that it does what you want. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [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 ? I don't want to lecture Vance about how he should go about doing the InHG to mBar conversion, but I think that his Nasal script should _only_ be executed when the altimeter setting is changed. IMHO it would be simpler to use the scale tag. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal
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 don't want to lecture Vance about how he should go about doing the InHG to mBar conversion, but I think that his Nasal script should _only_ be executed when the altimeter setting is changed. IMHO it would be simpler to use the scale tag. Sounds indeed very reasonable and less complicated if the conversion is the only thing he needs to be done. --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Nasal
Roy, I didn't think of using the scale tag; I'll take that route for the mBar conversion. Thanks, Vance -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roy Vegard Ovesen Sent: Thursday, November 18, 2004 5:31 AM To: [EMAIL PROTECTED] Subject: Re: [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 ? I don't want to lecture Vance about how he should go about doing the InHG to mBar conversion, but I think that his Nasal script should _only_ be executed when the altimeter setting is changed. IMHO it would be simpler to use the scale tag. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Nasal
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 scale tag? I can't find an example of its use for a 3D cockpit. animation typetextranslate/type object-namemb_digit_4/object-name property/instrumentation/altimeter/setting-inhg/property scale33.86/scale factor.0001/factor step1000/step !--scroll20/scroll-- axis x0/x y1/y z0/z /axis /animation Thanks again, Vance -Original Message- From: [EMAIL 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 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 lecture Vance about how he should go about doing the InHG to mBar conversion, but I think that his Nasal script should _only_ be executed when the altimeter setting is changed. IMHO it would be simpler to use the scale tag. Sounds indeed very reasonable and less complicated if the conversion is the only thing he needs to be done. --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal
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 the instrument files - e.g. the ADF panel is a good example. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-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 of the scale tag? I can't find an example of its use for a 3D cockpit. animation typetextranslate/type object-namemb_digit_4/object-name property/instrumentation/altimeter/setting-inhg/property scale33.86/scale factor.0001/factor step1000/step !--scroll20/scroll-- axis x0/x y1/y z0/z /axis /animation Thanks again, Vance Hmmm... I guess that the factor tag does the same for 3d as the scale tag does for 2d, so you should put 33.86 inside the factor tag, and remove the scale tag completely. But I'm not sure about this. I wish I had a clue about how to add text chunks to the 3d animation code :-| Here's another way of doing it: data/Aircraft/Spitfire/Models/boost.xml. The data between the interpolate and /interpolate tags converts inHg to psi and changes the output from absolute to gauge. You need to work out the factors involved by hand though. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Nasal
I have 4 3d quads that represent the 4 digits of a millibar display embedded in a 3D altimeter. I need to read inches HG from the property system, convert it to mbar and then use that as a texture translation offset for the quad digits. There are lots of examples for 2D gauges, but none for 3D gauges. Here's a portion of the code that drives the HG portion of the altimeter (This works fine). !-- inches HG display -- animation typetextranslate/type object-namehg_digit_4/object-name property/instrumentation/altimeter/setting-inhg/property factor0.01/factor step10/step !--scroll20/scroll-- axis x0/x y1/y z0/z /axis /animation animation typetextranslate/type object-namehg_digit_3/object-name property/instrumentation/altimeter/setting-inhg/property factor0.1/factor step1/step !--scroll20/scroll-- axis x0/x y1/y z0/z /axis /animation Works fine. Here's a bit of the code for the mbar digits (note that the conversion factor is multiplied into the factor (.001 * 33.6)): animation typetextranslate/type object-namemb_digit_3/object-name property/instrumentation/altimeter/setting-inhg/property factor0.0336/factor step100/step scroll20/scroll axis x0/x y1/y z0/z /axis /animation This doesn't work one bit. I initially thought, no problem, I'll embed some nasal into the altimeter's xml file but that isn't supported. I want to make the T6's cockpit fully functional so any suggestions 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 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 the instrument files - e.g. the ADF panel is a good example. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] nasal?
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 can copy it into the source/docs-mini/ directory. Looking through the webpages, I'm still having difficulties understanding how OOP is done on nasal. It's pretty straight-forward and there are even examples at plausible.org: http://www.plausible.org/nasal/sample.html - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Nasal
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 the docs, it's not clear to me where this code should reside. Can I put script code directly in the gauge's XML file (I've tried this and it doesn't seem to work)? Thanks, Vance ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal
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). After looking at the docs, it's not clear to me where this code should reside. Can I put script code directly in the gauge's XML file (I've tried this and it doesn't seem to work)? Actually, the instrument definitions themselves cannot yet contain Nasal statements, at least that's what I learnt about 3 weeks ago when I made a quick stab at another new instrument, I was also somewhat surprised but found my assumptions confirmed when I looked into the source code - so, in that regard FG is currently somehwat inconsistent, because it doesn't seem to support Nasal scripts in any PropertyList file. As a workaround you could simply place that script into a separate nasal module and put that into the Nasal sub folder, so that it gets automatically loaded - you can then refer to the code in that module by using the file's name (without extension) to access functions/objects. For debugging purposes it might be helpful to use print statements in order to see whether a function is actually called. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal
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 this for the texture translation). After looking at the docs, it's not clear to me where this code should reside. Can I put script code directly in the gauge's XML file (I've tried this and it doesn't seem to work)? Yes you can put nasal scripts in the action tags of the gauge's xml file: action ... commandnasal/command script![CDATA[ # Your nasal script for converting from InHG to mBar. ]] /script /binding /action -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] nasal?
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? Is the global parser good enough, can I just pass a script to it? What about the existing scripts, how are they found and launched? I'm not seeing how it all goes together. Thanks, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] nasal?
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 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? Is the global parser good enough, can I just pass a script to it? What about the existing scripts, how are they found and launched? I'm not seeing how it all goes together. This is pretty much covered on that page. The files in the Nasal directory of the base package are read and executed at the end of boot. Stuff in fg-command bindings is parsed and executed when the binding fires. Properties under /nasal are read during initialization and can contain either literal code or point to files to load. And there are C++ APIs from which you can turn a string into a FGNasalScript object with a call() method which can be invoked at runtime. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] nasal?
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. I suggested already some time ago that it would be nice to have all ;-) the Nasal docs available within $FG_ROOT/data/Docs ... As someone who had to 'learn' Nasal and how it interacts with FG I would have found it useful to have such info directly available within the base package - like all the other docs. Also, I assembled some simple howtos for myself about how to do certain things with Nasal, it would not be all that complicated to extend such a howto and possibly add some real life examples about FG-integration and make such files then generally available. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] nasal?
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 covered on that page. The files in the Nasal directory of the base package are read and executed at the end of boot. Stuff in fg-command bindings is parsed and executed when the binding fires. Properties under /nasal are read during initialization and can contain either literal code or point to files to load. And there are C++ APIs from which you can turn a string into a FGNasalScript object with a call() method which can be invoked at runtime. Ok, just to be difficult, let's say that my nasal code isn't really appropriate for the global nasal directory, it's not really tied to a specific aircraft configuration, and I'm not sure I could populate /nasal early enough in the init sequence to get a file automatically loaded. Am I on my own to open and load a file into a buffer and pass that to the nasal interpreter? Thanks Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] nasal?
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 into the source/docs-mini/ directory. Looking through the webpages, I'm still having difficulties understanding how OOP is done on nasal. Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal multiple contexts (was: AI carrier)
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 ready for the ground velocity and arrestor wire position values. Personally, I would find it VERY useful if Nasal could run recursively, respectively with several contexts: I am now at a point, where timers simply won't work anymore for every case, and some other things that I wanted to do, like dynamically updatable GUI controls would also be easier to implement if there was a way to use a callback mechanism with Nasal or at least if I were able to call Nasal Nasal code from within Nasal scripts. I did look into your code, but to be honest: the odds to get it done seem to be A LOT better if you tell me what would be involved, I simply lack the understanding of how exactly you implemented all this. So I really don't know how long it might take to get that done. But even if you shouldn't decide to take care of that within the near future, I'd like to get some feedback about the feasibility of making Nasal run with multiple contexts, so that I can assess whether it makes sense to really dig into it or not. Thanks - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Nasal - Question
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 /controls I then try to access it elsewhere. This works: binding commandnasal/command script setprop(controls/engines/engine/magneto-switch[0],1); /script /binding But this doesn't: binding commandnasal/command script setprop(controls/engines/engine/magneto-switch[1],1); /script /binding 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 Internal Properties dialog either. I think that it may be a property tree issue rather than Nasal. Any guidance/ideas? Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal - Question
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 /engines /controls I then try to access it elsewhere. This works: binding commandnasal/command script setprop(controls/engines/engine/magneto-switch[0],1); /script /binding But this doesn't: binding commandnasal/command script setprop(controls/engines/engine/magneto-switch[1],1); /script /binding 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 Internal Properties dialog either. I think that it may be a property tree issue rather than Nasal. Any guidance/ideas? Does your spitfire have more than one magneto switch? This generally implies more than one engine. The value of the first magneto-switch[0] is probably what you want to be changing. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal - Question
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 type=bool1/magneto-switch /engine /engines /controls I then try to access it elsewhere. This works: binding commandnasal/command script setprop(controls/engines/engine/magneto-switch[0],1); /script /binding But this doesn't: binding commandnasal/command script setprop(controls/engines/engine/magneto-switch[1],1); /script /binding 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 Internal Properties dialog either. I think that it may be a property tree issue rather than Nasal. Any guidance/ideas? Does your spitfire have more than one magneto switch? This generally implies more than one engine. The value of the first magneto-switch[0] is probably what you want to be changing. Regards, Curt. I thought most piston planes had two magnetos per engine ... Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal - Question
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 type=bool1/magneto-switch /engine /engines /controls I then try to access it elsewhere. This works: binding commandnasal/command script setprop(controls/engines/engine/magneto-switch[0],1); /script /binding But this doesn't: binding commandnasal/command script setprop(controls/engines/engine/magneto-switch[1],1); /script /binding 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 Internal Properties dialog either. I think that it may be a property tree issue rather than Nasal. Any guidance/ideas? Does your spitfire have more than one magneto switch? This generally implies more than one engine. The value of the first magneto-switch[0] is probably what you want to be changing. Regards, Curt. I thought most piston planes had two magnetos per engine ... 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 the magneto-switch[0] value. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Nasal - Question
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 type=bool1/magneto-switch magneto-switch type=bool1/magneto-switch /engine /engines /controls I then try to access it elsewhere. This works: binding commandnasal/command script setprop(controls/engines/engine/magneto-switch[0],1); /script /binding But this doesn't: binding commandnasal/command script setprop(controls/engines/engine/magneto-switch[1],1); /script /binding 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 Internal Properties dialog either. I think that it may be a property tree issue rather than Nasal. Any guidance/ideas? Does your spitfire have more than one magneto switch? This generally implies more than one engine. The value of the first magneto-switch[0] is probably what you want to be changing. Regards, Curt. I thought most piston planes had two magnetos per engine ... 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 the magneto-switch[0] value. Regards, Curt. The physical aircraft has 2 magnetos and two switches, and a separate starter (a Coffman cartridge starter - but that's a longer term problem). I know that the magneto property has values 0,1,2,3 but my solution was to model the switches first - I have (had) a cunning plan. But that's not really the question - I can work around the problem - but why doesn't the script work? V. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
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 starter power is rolled in too.) If the physical aircraft has a separate switch for each magneto, then the underlying logic should just change the magneto-switch[0] value. The physical aircraft has 2 magnetos and two switches, and a separate starter (a Coffman cartridge starter - but that's a longer term problem). 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 appropriate booleans on the engines based on the 4 switch position values. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
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-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 Internal Properties dialog either. I think that it may be a property tree issue rather than Nasal. Any guidance/ideas? I dunno, this all looks correct to me, both the Nasal and the XML definitions. The fact that you can't read it in the browser is especially weird. Maybe there's a tie or an alias that's getting in the way? Try binding a key to do: props.dump(props.globals.getNode(/controls/engines/engine)); And see what you find. This will crawl the specified property tree and recursively dump all the sub-properties, with their types. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal - Question
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 appropriate booleans on the engines based on the 4 switch position values. I agree. Some older planes do have the starter separate from the magneto switch. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Nasal - Question
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 starter power is rolled in too.) If the physical aircraft has a separate switch for each magneto, then the underlying logic should just change the magneto-switch[0] value. The physical aircraft has 2 magnetos and two switches, and a separate starter (a Coffman cartridge starter - but that's a longer term problem). 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 appropriate booleans on the engines based on the 4 switch position values. Hah! You have sussed out the cunning plan ... Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Nasal - Question
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-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 Internal Properties dialog either. I think that it may be a property tree issue rather than Nasal. Any guidance/ideas? I dunno, this all looks correct to me, both the Nasal and the XML definitions. The fact that you can't read it in the browser is especially weird. Maybe there's a tie or an alias that's getting in the way? Try binding a key to do: props.dump(props.globals.getNode(/controls/engines/engine)); And see what you find. This will crawl the specified property tree and recursively dump all the sub-properties, with their types. Done that - all looks as it should. ../magneto-switch[1]is not set here either. However, a new fact that I hadn't noticed before, is that when accessing ../magneto-switch[1] through the Browse Internal Properties dialog it sets ../magneto-switch[0]. Weird or what? Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal in instrument config (was:YASim fuel problem)
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 will print Hello World! on the console. It
will *not* print Executing myFunction()!. But later on some other
piece of Nasal code could do:
B52F.myFunction();
Which would then print Executing myFunction()!.
I tried this inside an instrument config file, but it didn't work.
Would it be possible to implement the ability to include nasal code in
instrument config files. I know that one can have nasal code for the action
bindings. What I want is to define some nasal functions that are instrument
specific.
I've done this with a global nasal script in the Nasal subdirectory, but as
more instruments use nasal it seems wastefull to have a lot of global nasal
code that never get used. Example: the KAP140 autopilot control panel uses
the Nasal/kap140.nas script. AFAIK currently the only aircraft that uses the
KAP140 is the C172, but still the kap140.nas is executet for every aircraft.
One could put the kap140.nas in the *set.xml for the aircrafts that use the
KAP140 instrument, but I believe it would be better to make it instrument
specific.
--
Roy Vegard Ovesen
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal in instrument config
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 instrument config files. Yes, but I'm not sure how to do it cleanly. The scripting subsystem can't simply crawl through the whole property tree looking for nodes that look like instruments. What needs to happen is for the instrument layer to recognize the script and hand it to the Nasal manager as an initialization hook. But that begs more questions: do you want your initialization called once globally, or once for each instance of the instrument? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal bug in keyboard binding
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 there isn't a symbolic debugger for Nasal
yet. :)
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)?
One thing I noticed just recently is that the top-level C++ code for
timers (as opposed to input bindings) did not properly print the stack
trace on error. I have this fixed in my tree; I suppose I need to get
it checked in before Curt forks 0.9.4. :)
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal bug in keyboard binding
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 mind, I understand. The getprop() function returns nil if the
SGPropertyNode type of the property is UNSPECIFIED. That's definitely
a bug. Fixed.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal bug in keyboard binding
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 alert. It's true that there isn't a symbolic debugger for Nasal
yet. :)
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)?
If you have xml:
propertytrue/property
then the test
if (property) {
}
will fail.
If you have xml:
property type=booltrue/property
then the test
if (property) {
}
will work.
At least this is what I think I was seeing.
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] nasal question
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 /SetHeadingBug /nasal 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? Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal question
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 after a timeout.
Something like this will work:
SRCPROP = /orientation/heading-magnetic-deg;
DSTPROP = /autopilot/settings/heading-bug-deg;
DELAY = 1;
settimer(func { setprop(SRCPROP, getprop(DSTPROP)) }, DELAY);
You will probably need to experiment to find a value of DELAY that
works on all systems. What is *really* needed here is a way to tell
when initialization is done, and hook in a callback for that. Right
now the various subsystems finish their work at different times, which
causes problems like this one.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal question
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 initializes.
Dave
--
David Culp
davidculp2[at]comcast.net
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal Sockets...
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 you need to do with it? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal Sockets...
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 you need to do with it? It's not something I particualrly need, it comes from something on another project. I'm working with a commercial game developer to add data exports to their simulator and since they use Lua script (http://www.lua.org) already, they're just going to add Lua functions to access internal state data that can be then be sent to the outside world via a socket add-in called LuaSocket. This got me thinking about how FlightGear uses Nasal and how it could be used similarly to Lua for this task. It would allow for a more flexible system to import and export data to FG than the current xml defined, text-only net interface does now. This could work well if the Nasal script could be executed at a rate of 20Hz or so. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Nasal question
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 ground handling (I know it won't make a big difference, but I want to try it) and also so that when I animate brake pedals they don't just snap back and forth. 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. I played around with stepProp but I couldn't set the /sim/brakes properties from inside the joystick config file, so I gave up on that. I think I need some clarification on how these are supposed to work before I can figure out how to do this. Thanks, Josh What I have now: button n=1 descLeft Brake/desc repeatable type=boolfalse/repeatable binding commandproperty-assign/command property/controls/gear/brake-left/property value type=double1.0/value /binding mod-up binding commandproperty-assign/command property/controls/gear/brake-left/property value type=double0.0/value /binding /mod-up /button What didn't work: button n=1 descLeft Brake/desc repeatable type=boolfalse/repeatable binding commandnasal/command scriptcontrols.slewProp(/controls/gear/brake-left, 1)/script /binding mod-up binding commandnasal/command scriptcontrols.slewProp(/controls/gear/brake-left, -1)/script /binding /mod-up /button ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal question
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() function slews a property by the appropriate amount for the current frame only (based on the time it took to render the last frame). If you only call it once when the button is pressed/released, you will only get one frame of motion. The time will look inconsistant because individual frames take varying times to render. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal question
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 repeatable tags don't affect anything inside a mod-up tag. In retrospect, this makes a lot of sense. For this will I have to implement something like the flaps using stepProp? If so, will I have to make changes outside of the joystick file to define a hash for nasal? Is there a utility function to move a property from value a to value b over a given delta? I looked but didn't see anything that said it would do that. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal question
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 /binding mod-up repeatable type=booltrue/repeatable binding commandnasal/command scriptinterpolate(/controls/gear/brake-left, props.globals.getNode(/controls/gear/brake-left).getValue(), 0, 0, 0.1)/script /binding /mod-up /button ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal question
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 need for the first two arguements. This call should have the same effect: interpolate(/controls/gear/brake-left, target-value, 0.1) And a more general note: the getValue() expression can be more simply (and efficiantly, for that matter) written as: getprop(/controls/gear/brake-left) The props.Node interface is there for completeness and flexibility, but grabbing constant strings out of the the property tree is best done with the simple API. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Nasal/Saitek X45
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 mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal/Saitek X45
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 stick, but I've got an X45 too - So I guess I'll go try it out :-) I think I've still got a wingman 3d somewhere too - if I can find it I'll do a file for it. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Nasal control bindings
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 to refcount it. Nasal did, which
caused the node to be prematurely freed. Trivial fix; horrific
debugging effort. :(
So I've started checking in my Nasal control/input changes. The
keyboard bindings are first, because they're easier to test. I'll get
to the joystick bindings as soon as I can. With one or two
exceptions, nothing should be visibly different to the user. Notable
changes:
+ The v/V bindings for stepping through views are no longer hardcoded
in the XML, and pop up a nice eye-candy label to tell you what view
you have selected. I'll leave it to someone else to come up with a
translation of Chase View wo yaw :)
+ Flap steppings are now settable per-aircraft. You can have as many
as you like; the up/down flaps bindings do the right thing. I set
up a sample in the 747-yasim-set.xml configuration. The syntax is
very simple (I have no idea if these values are right, though):
flaps
setting0.00/setting
setting0.01/setting
setting0.02/setting
setting0.05/setting
setting0.10/setting
setting0.33/setting
setting0.67/setting
setting1.00/setting
/flaps
There is compatibility code in place so that aircraft without a
/sim/flaps[n] declaration will get the old 0.0/0.33/0.66/1.0
steppings. Note that only the *keyboard* bindings are currently
using this code.
+ Engine settings automatically detect and set properties for the
correct number of engines. No more need to duplicate XML bindings
for a maximum number. The XML files are a *lot* smaller for this.
+ The popup tip label used for the zoom and (now) view change code
is available for general use as gui.popupTip('My tip message');.
+ There is a slewProp() implementation that handles realtime-based
motion of property values. This will eliminate the framerate
dependencies of trim and view direction changes for joystick
handlers. Note that this is *not* used by the keyboard handlers,
becuase the OS generates its own key repeats that we'll have to turn
off first.
I've tried to test this, but something probably slipped through. Let
me know if I broke something. I'll hopefully have a chance to work on
the joystick bindings tonight.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Nasal code/continuous loop
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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal code/continuous loop
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.
Probably the best way to do this is with interpolate(). This code
should swing the pitch linearly between -10 and +10 and back 5 times
over 10 seconds, and then set a timer to do it again:
rockBoat = func {
# Arguments: property, value, delta, value, delta, ...
# Start at 10 degrees immediately, then back and forth five times:
interpolate(/sim/ai/wherever/boat/pitch-deg, -10, 0,
10, 1, -10, 1,
10, 1, -10, 1,
10, 1, -10, 1,
10, 1, -10, 1,
10, 1, -10, 1);
# When we're done, start it again:
settimer(rockBoat, 10);
}
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.
With a little work, you could populate that table with random numbers,
etc... This avoids the need to run a Nasal script every frame to
iterate your animation; the interpolator is a C++ module.
A useful feature that doesn't yet exist would be the ability to
register a callback function for the end of an interpolation; this
would eliminate the need for the settimer call and any race conditions
that result from slightly different timeouts.
That would be really nice.
BTW. No need to hurry on this, I was just experimenting with Nasal a bit
and (although I would get something like this implemented sometime) the
code to add an AI model using Nasal isn't available either.
What you are asking for, the ability to run a script in a loop
forever, will require more work. This would essentially be a
multithreaded interpreter, and the NasalSys subsystem would have to
maintain separate execution contexts for each thread. That is, by
design, supposed to work in Nasal, But for this kind of animation
problem, it's probably not the right solution. The per-thread
overhead is rather high.
Agreed, an event method would be best, but I couldn't find the right
solution.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal code/continuous loop
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; frame rate doesn't effect it. It runs only once per frame, but the property changes it manages are based on actual time deltas. The 5Hz update will affect the granularity of settimer() calls, but over 10 seconds the error is negligible. You might see a skip once every 10 seconds as the timer resets. Even that can be hidden by removing the first two arguments of the interpolate call (which set the value by interpolating over a zero time delta) and initializing the property somewhere else. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Nasal again
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 fileAircraft/c172/c172.nas/file /c172 /nasal This defines a c172 module initialized by the specified file. There are a few more details. I've updated the documentation at: http://www.plausible.org/andy/fg-nasal.html to reflect them, along with the features from yesterday. Have fun, Andy -- Andrew J. RossBeyond the OrdinaryPlausibility Productions Sole Proprietor Beneath the Infinite Hillsboro, OR Experience... the Plausible? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Nasal integration docs
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 already available (at http://www.plausible.org/nasal/). This is a hopefully readable tutorial on exactly how Nasal hooks into FlightGear, how to execute Nasal code and how to hook C++ functions from a running Nasal script. Let me know what isn't clear. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Nasal integration
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 source, data and SimGear directories inside the tarball.]
Obviously people are going to have differing opinions on whether this
language is worth pursuing. I've chosen to fight the other
alternatives via relentless integration. This code actually does
useful things. (I said integrated, by the way, not debugged. :)
+ Like the existing PSL engine, it can be used to define command
bindings and get and set properties in the global tree.
And there are a few new features:
+ You can call globally defined FlightGear commands, allowing
scriptable control over the GUI, for example. You can even call a
PSL command from a Nasal script if you want. (Amusingly, you
*can't* call a nasal command from a Nasal script -- there's only
one context object in the current implementation and you'll corrupt
your call stack. Obviously no one would want to do this, though.)
+ You can write whole files of script code by dropping .nas files
into the Nasal directory of the base backage. These are parsed and
interpreted at startup, and can hold any code or data you like.
And becasue Nasal pretends to be a Real Language, it has a few and
advantages (IMHO) over the PSL stuff:
+ It is much richer, semantically. You have vectors and hashes, OOP
syntax, inheritance, functional programming, etc...
+ You can write your code in whole source files, store data in
persistent variables and organize it into modules with real
namespaces. Emacs users even have access to a mostly-working
nasal-mode.el that I hacked together (don't laugh; I basically
blind-copied awk-mode.el and tried to avoid changing the things I
didn't understand).
+ The flip side is that because of the ability to abstract complicated
stuff out into modules, the XML-side configuration can be much
cleaner. The existing keyboard C binding looks like this when
written in PSL:
binding
commandscript/command
script
int main ()
{
print(Longitude: , get_property(/position/longitude-deg),
deg\n);
print(Latitude: , get_property(/position/latitude-deg),
deg\n);
print(Altitude: , get_property(/position/altitude-ft), ft\n);
}
/script
/binding
But shortens to this when you put your code into a test.nas module
(and you don't need the silly main() declaration because Nasal
expressions and statments are grammatically identical; but that's
only a mild PSL misfeature):
binding
commandnasal/command
script test.handleTestKeyEvent() /script
/binding
The rest of the world looks very similar. The way that Nasal is
integrated mirrors the PSL engine almost exactly. Neither touches the
core of FlightGear much at all; they just hook a new subsystem into
the global list. SimGear is affected only in that it gets a new
directory and a new library to build.
There is some (admittedly terse) documentation on the language
available at:
http://www.plausible.org/nasal/
http://www.plausible.org/nasal/doc.html
http://www.plausible.org/nasal/sample.nas
Nasal scripts have access to a small standard library of useful data
structure and math functions plus the following FlightGear-specific
ones:
+ print() - Concatenates and writes out its arguments via SG_LOG()
+ getprop() - Fetches a property from the global tree. Will accept a
variable-length list of arguments and append them together to form
a property name. This is so that you can do stuff like:
getprop(/sim/mode/space-wars);
getprop(CurrentGalaxy, size-parsecs);
+ setprop() - Ditto.
+ fgcommand() - First argument specifies a FlightGear command name,
second is the path of a property sub-node where you have placed
the arguments to the command.
Over the next few days, I'm going to try to write some non-trivial
example code (the existing test.nas module is attached to this
message) and maybe code up a few enhancements. Useful future stuff
might be:
+ A timer API, so you can register callbacks for a specified time
and/or interval. Almost the whole ATC subsystem could be based on
such a mechanism, for example.
+ A threading API, where a script could run in a loop forever making
blocking calls (waitfor(), or somesuch). This kind of programming
is wasteful and fraught with race conditions, but still a good fit
for some problems (AI, for example).
+ Hooks into more FlightGear subsystems. The GUI module doesn't work
in the main property tree, so it will require just a little bit of
work to integrate. But raw PUI bindings might not be a bad idea
either.
+ A wrapped object library for SGPropertyNode, so you can use the
property system more like you do in C++.
+ Lots of new library
RE: [Flightgear-devel] Nasal integration
I just want to know: why nasal? :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal integration
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 thinking had led earlier to YASim, which has done relatively well as names go. But alas, it wasn't to be. It turns out that the Nessus network security project (www.nessus.com) have had their own Nessus Attack Script Language for several years. The world just isn't big enough for two NASLs, unfortunately.* They emailed me just days after I had posted to Freshmeat. [* Yeah, right. Like I was going to fight this and make enemies of a whole project full of network security experts.] Anyway, at that point I was too lazy to go through the code to change the naXXX's to something else. Calling it Nasal got me out of trouble with the scary white hats and allowed me to keep the pronunciation and the C prefix. Jon S. Bertdt wrote: I just want to know: why nasal? Like I said. I don't have a clue. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Nasal integration
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] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
