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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
