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
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
[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 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
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: 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. 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 vs. gcc 4.0.x
On Donnerstag 11 August 2005 01:37, Andy Ross wrote: > 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. Using fc4 for some weeks now. 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. Do you already know which file is misscompiled? 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
[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
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 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)
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)
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
[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 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" 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
Nevermind. I found the Nasal docs. - Original Message - From: <[EMAIL PROTECTED]> To: "FlightGear developers discussions" Sent: Thursday, June 09, 2005 4:26 PM Subject: Re: [Flightgear-devel] NASAL error I know this is an incredibly dumb question.. but in Nasal an "elseif" conditon is expressed as "elsif"? - Original Message - From: "Josh Babcock" <[EMAIL PROTECTED]> To: "FlightGear developers discussions" Sent: Thursday, June 09, 2005 3:59 PM Subject: [Flightgear-devel] NASAL error OK, this works great: (other than the fact that it doesn't actually do anything yet) gearLightCheck = func { for (i=0; i<3; i=i+1) { thisProp = "/gear/gear[" ~ i ~ "]/position-norm"; if ( getprop(thisProp) == 1 ) { print("green"); } elsif ( getprop(thisProp) == 0 ) { print("off"); } else { print("red"); } } settimer(gearLightCheck, 5); } but this gearLightCheck = func { for (i=0; i<3; i=i+1) { thisProp = "/gear/gear[" ~ i ~ "]/position-norm"; if ( getprop(thisProp) == 1 ) { print("green"); } elsif ( getprop(thisProp) < 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: true false 0 0 0 0 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 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
I know this is an incredibly dumb question.. but in Nasal an "elseif" conditon is expressed as "elsif"? - Original Message - From: "Josh Babcock" <[EMAIL PROTECTED]> To: "FlightGear developers discussions" Sent: Thursday, June 09, 2005 3:59 PM Subject: [Flightgear-devel] NASAL error OK, this works great: (other than the fact that it doesn't actually do anything yet) gearLightCheck = func { for (i=0; i<3; i=i+1) { thisProp = "/gear/gear[" ~ i ~ "]/position-norm"; if ( getprop(thisProp) == 1 ) { print("green"); } elsif ( getprop(thisProp) == 0 ) { print("off"); } else { print("red"); } } settimer(gearLightCheck, 5); } but this gearLightCheck = func { for (i=0; i<3; i=i+1) { thisProp = "/gear/gear[" ~ i ~ "]/position-norm"; if ( getprop(thisProp) == 1 ) { print("green"); } elsif ( getprop(thisProp) < 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: true false 0 0 0 0 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
Josh Babcock wrote: > OK, this works great: (other than the fact that it doesn't actually do > anything yet) > > gearLightCheck = func { > for (i=0; i<3; i=i+1) { > thisProp = "/gear/gear[" ~ i ~ "]/position-norm"; > if ( getprop(thisProp) == 1 ) { > print("green"); > } elsif ( getprop(thisProp) == 0 ) { > print("off"); > } else { > print("red"); > } > } > settimer(gearLightCheck, 5); > } > > but this > > gearLightCheck = func { > for (i=0; i<3; i=i+1) { > thisProp = "/gear/gear[" ~ i ~ "]/position-norm"; > if ( getprop(thisProp) == 1 ) { > print("green"); > } elsif ( getprop(thisProp) < 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: > > > >true >false > > 0 > > > 0 > > > 0 > > > 0 > > > > > 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
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
[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; i<3; 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; i<3; 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: true false 0 0 0 0 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 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: > 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 update YASim parameters
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. > > Andy > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > I don't think the LG thing will work, they have to be extended independently of the LG. In fact, if you're moving and have both gear down and doors open, your plane's broke or you screwed up. (at some point I will put in an emergency door release and bomb release, but that's fluff for way down the road). Speedbrakes would be great, though I would request that there be capacity for multiple independent ones, just on the general principal of flexibility. Thanks, 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
[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 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 advice...
> From: Andy Ross > > 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 A 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...
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" c"A" 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...
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
[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 c"A" 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" c"A" 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; ihttp://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 > > > textranslate > mb_digit_3 > /instrumentation/altimeter/setting-inhg > > >29.50 >0.9 > > >29.90 >0.0 > > > > 100 ^ What's this??? > > >0 >1 >0 > > > 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
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 textranslate mb_digit_3 /instrumentation/altimeter/setting-inhg 29.50 0.9 29.90 0.0 100 0 1 0 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vance Souders Sent: Friday, November 19, 2004 10:19 AM To: 'FlightGear developers discussions' Subject: 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 tag? I > > can't find an example of its use for a 3D cockpit. > > > > > > textranslate > > mb_digit_4 > > /instrumentation/altimeter/setting-inhg > > 33.86 > > .0001 > > 1000 > > > > > >0 > >1 > >0 > > > > > > > > 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 and 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] 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 tag? I > > can't find an example of its use for a 3D cockpit. > > > > > > textranslate > > mb_digit_4 > > /instrumentation/altimeter/setting-inhg > > 33.86 > > .0001 > > 1000 > > > > > >0 > >1 > >0 > > > > > > > > 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 and 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
On Thursday 18 November 2004 17:59, Boris Koenig wrote: > 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 ? I would like to be able to do the same for the 3d animation config that I can do for the 2d panel config: make text chunks that can display the contents of properties as text. -- Roy Vegard Ovesen ___ 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). textranslate hg_digit_4 /instrumentation/altimeter/setting-inhg 0.01 10 0 1 0 textranslate hg_digit_3 /instrumentation/altimeter/setting-inhg 0.1 1 0 1 0 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)): textranslate mb_digit_3 /instrumentation/altimeter/setting-inhg 0.0336 100 20 0 1 0 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
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 tag? I > > can't find an example of its use for a 3D cockpit. > > > > > > textranslate > > mb_digit_4 > > /instrumentation/altimeter/setting-inhg > > 33.86 > > .0001 > > 1000 > > > > > >0 > >1 > >0 > > > > > > > > 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 and 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
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
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 tag? I > can't find an example of its use for a 3D cockpit. > > > textranslate > mb_digit_4 > /instrumentation/altimeter/setting-inhg > 33.86 > .0001 > 1000 > > >0 >1 >0 > > > > 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 :-| -- Roy Vegard Ovesen ___ 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 tag? I can't find an example of its use for a 3D cockpit. textranslate mb_digit_4 /instrumentation/altimeter/setting-inhg 33.86 .0001 1000 0 1 0 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, 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
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
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 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: 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 ? - 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: ... nasal -- Roy Vegard Ovesen ___ 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
[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?
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?
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?
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?
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?
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
[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 & 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
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 - 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 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
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
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
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 > >>> > >>> > >>> 1 > >>> 1 > >>> > >>> > >>> > >>> > >>> > >>> I then try to access it elsewhere. > >>> > >>> This works: > >>> > >>> nasal > >>> > >>> setprop("controls/engines/engine/magneto-switch[0]",1); > >>> > >>> > >>> But this doesn't: > >>> > >>> nasal > >>> > >>> 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? > >> > >> > >> 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
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 1 1 I then try to access it elsewhere. This works: nasal setprop("controls/engines/engine/magneto-switch[0]",1); But this doesn't: nasal 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? 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 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 1 1 I then try to access it elsewhere. This works: nasal setprop("controls/engines/engine/magneto-switch[0]",1); But this doesn't: nasal 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? 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
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 1 1 I then try to access it elsewhere. This works: nasal
setprop("controls/engines/engine/magneto-switch[0]",1);
But this doesn't: nasal
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? 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
[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 1 1 I then try to access it elsewhere. This works: nasal setprop("controls/engines/engine/magneto-switch[0]",1); But this doesn't: nasal 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? Regards Vivian ___ 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 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: > > > > >myFunction = func { print("Executing myFunction()!"); } >print("Hello World!\n"); > > ]]> > > > > 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 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: true then the test if (property) { } will fail. If you have xml: true 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 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
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
Jim Wilson said: > Well I was going to suggest that we don't need two xml files one for 3D and 2D > cockpits because we can easily switch back and forth, as illustrated by the > "c" key binding, but then I discovered a problem: > > 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 so if someone doesn't come forward I will return it > to the xml format that used to work just fine. > Nevermind for now, there's a workaround coming. if (property) { } Does not work if the "property" type is undefined. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] nasal bug in keyboard binding
Well I was going to suggest that we don't need two xml files one for 3D and 2D cockpits because we can easily switch back and forth, as illustrated by the "c" key binding, but then I discovered a problem: 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 so if someone doesn't come forward I will return it to the xml format that used to work just fine. Best, Jim ___ 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 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
[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: setprop("/autopilot/settings/heading-bug-deg", getprop("/orientation/heading-magnetic-deg")); 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 & 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 & 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
[Flightgear-devel] Nasal & Sockets...
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? tnx! g. ___ 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", , 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 question
Never mind. I just remembered interpolate. This works perfectly. Josh Left Brake true nasal interpolate("/controls/gear/brake-left", props.globals.getNode("/controls/gear/brake-left").getValue(), 0, 1, 0.1) true nasal interpolate("/controls/gear/brake-left", props.globals.getNode("/controls/gear/brake-left").getValue(), 0, 0, 0.1) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal question
Andy Ross wrote: 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
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
[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: Left Brake false property-assign /controls/gear/brake-left 1.0 property-assign /controls/gear/brake-left 0.0 What didn't work: Left Brake false nasal controls.slewProp("/controls/gear/brake-left", 1) nasal controls.slewProp("/controls/gear/brake-left", -1) ___ 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/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 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 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: > 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); } 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. 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. 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
[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): 0.00 0.01 0.02 0.05 0.10 0.33 0.67 1.00 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 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: Aircraft/c172/c172.nas 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
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
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
I just want to know: why "nasal"? :-) ___ 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: 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"); } 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): nasal test.handleTestKeyEvent() 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 functions. What's there now is pretty basic: just