Re: [Flightgear-devel] Re: NASAL Scripted Pushback
Carsten Hoefer wrote: BTW: How do I play sounds by Nasal scripts? The same way one would do animations using Nasal; Adjust properties in Nasal (they may be private properties in your own subtree of the property list, say /tmp/aircraft) and let the sound configuration file act on those properties. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: NASAL Scripted Pushback
Andy Ross schrieb: Steve Knoblock wrote: 1. Will Nasal scripting give me all options to program the push-back function (incl. playing sound files and checking distances to other planes or to next taxi way)? I am not sure of this, but NASAL can listen for properties and then change properties, Yes, Nasal interacts with the rest of FlightGear through the property and FGCommand subsystems, and in a few special cases by extension functions (settimer() and random() being the only ones I can think of off the top of my head). So anything you can do through those mechanisms is scriptable. Anything the you *can't* do through those mechanisms is either something that we don't want to script (3D rendering, FDM internals), or just haven't gotten around to. Wiring up property/command interfaces for C++ subsystems is generally pretty easy. Andy Ok, it looks like I'm able to set the body velocity (uBody) to a certain value by a nasal-script and the plane makes some kind of hoop forward. But I got the impression, that the fdm automatically 'resets' my velocity to the correct value generated by the thrust of the engine. I did try to set the value in a for-loop, but this only sets the velocity x-thousand times to a value without moving the plane. So is there any way to update the graphics in a loop or to set a rearward velocity for a certain distance/time? BTW: How do I play sounds by Nasal scripts? TIA, Carsten ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: NASAL Scripted Pushback
On Tue, 29 Nov 2005 05:57:53 -0600, you wrote: or just haven't gotten around to. Wiring up property/command interfaces for C++ subsystems is generally pretty easy. Andy Is there a list of all properties or commands available or how do I find the appropriate functions? I allready found the readme.properties, but looking at Steve's autopilot.nas I can see some more properties that are not listed in the readme. Setting a property that does not exist in the property tree creates it. This gives you the ability to create your own properties in the FlightGear property tree just by bringing them into existence in your NASAL script. I created some properties for internal use by the autopilot. The idea cane from looking at KAP140 autopilot code. You may want to look at that, which mine is partly based on. The reason for creating my own properties was to isolate properties that are special to the particular autopilot and to keep the properties organized. I did have some trouble finding out what properties are available. I looked through every .nas and XML file I could find in the distribution until I had a good idea of the properties I needed. I read the list of properties in the source documentation. I watched some properties in the property viewer (on the File menu). I am unsure if there is a complete and comprehensive list of default FlightGear properties yet. Someone should know on the list. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: NASAL Scripted Pushback
Steve Knoblock wrote: 1. Will Nasal scripting give me all options to program the push-back function (incl. playing sound files and checking distances to other planes or to next taxi way)? I am not sure of this, but NASAL can listen for properties and then change properties, Yes, Nasal interacts with the rest of FlightGear through the property and FGCommand subsystems, and in a few special cases by extension functions (settimer() and random() being the only ones I can think of off the top of my head). So anything you can do through those mechanisms is scriptable. Anything the you *can't* do through those mechanisms is either something that we don't want to script (3D rendering, FDM internals), or just haven't gotten around to. Wiring up property/command interfaces for C++ subsystems is generally pretty easy. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: NASAL Scripted Pushback
Andy Ross schrieb: Steve Knoblock wrote: 1. Will Nasal scripting give me all options to program the push-back function (incl. playing sound files and checking distances to other planes or to next taxi way)? I am not sure of this, but NASAL can listen for properties and then change properties, Yes, Nasal interacts with the rest of FlightGear through the property and FGCommand subsystems, and in a few special cases by extension functions (settimer() and random() being the only ones I can think of off the top of my head). So anything you can do through those mechanisms is scriptable. Anything the you *can't* do through those mechanisms is either something that we don't want to script (3D rendering, FDM internals), or just haven't gotten around to. Wiring up property/command interfaces for C++ subsystems is generally pretty easy. Andy Is there a list of all properties or commands available or how do I find the appropriate functions? I allready found the readme.properties, but looking at Steve's autopilot.nas I can see some more properties that are not listed in the readme. How will I know if a property is read-only or if I have a bug in my code? Thanks, Carsten ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Nasal advice...
Melchior FRANZ wrote: Wouldn't work in my case. Would only make it even less elegant. Then I better stick with this: Only if you don't want to write your own functions (in which case every feature I don't want to support is going to be inelegant and you'll never win until I turn Nasal into another monstrosity like perl). Write a function to turn a number into a 4 byte string (or more, you technically can do up to 6 in an IEEE double). Write a function to set or get a bit in a string. Write a function to turn a 4 byte string into a number. Compose them appropriately to set bits in numbers. Probably four lines of code, and you can do: setprop(name, setbit(getprop(name), 2)); Look more elegant than bit twiddling to my eyes... The problem is that in joystick files I don't have the possibility to initialize bit fields or define bit operations. Stick the bit stuff (which clearly isn't joystick-dependent) in globals.nas. Problem solved. Once again, bit operations on floating point numbers won't work like you want them to. Think about implementing sign extension in shifts, or rotations, or even (off the top of your head) tell me how many bits are retained when you left shift. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Nasal advice...
I wrote:
Write a function to [...]. Compose them appropriately to set bits
in numbers. Probably four lines of code,
Turns out it's three lines of code:
n2s = func(n) { var s = buf(6); setfld(s, 0, 48, n); return s; }
getbit = func(n, b) { getfld(var s = n2s(n), b, 1) }
setbit = func(n, b) { setfld(var s = n2s(n), b, 1); return fld(s, 0, 48); }
These guys provide 48 bits in a number. You can theoretically stretch
that to 53, but it requires some fiddling of the doubles that I don't
want to promise yet. :)
Obviously you can't use this yet, because I haven't written the
underlying bit functions. But hopefully this will address the
elegance issues.
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Nasal advice...
Melchior FRANZ wrote:
Alternatively, take TeX's syntax: `\A ... for extra geek points. ;-)
If you are really seeking for ggek points:
$eq1 = 2 * $val;
$eq2 = -7 + $val;
test_val = (1 (3 + #-3 * ${want_eq1 ? $eq1 : $eq2});
:-)
Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Nasal advice...
Melchior FRANZ * Vivian Meazza -- Sunday 24 April 2005 20:41: Andy Ross wrote `A` @A $A %A A @A $A %A A cA Anything but `A` - I'm bound to misread that in the future sometime. I favour a function. Hmm ... and I changed my mind and would now find `A` a reasonable choice. :-P You would change your mind - ask 3 programmers and get 4 answers :-). ` and ' *are* different characters. They *have* to look different, otherwise they are pointless. Every Unix shell considers them functionallly different. Nobody has complained )to me) so far. If a font doesn't show a clear difference, then it's the font that is broken, not the glyph. And then, with proper syntax coloring a character and a string constant have different colors. Alternatively, take TeX's syntax: `\A ... for extra geek points. ;-) Nothing wrong with the font - it's the reader that's broken. I suppose you work on the basis of why make it difficult when with a bit of extra effort you can make it impossible? Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Nasal
Melchior, That was exactly what I needed Thanks, Vance -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Melchior FRANZ Sent: Friday, November 19, 2004 12:05 PM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Re: Nasal * Vance Souders -- Friday 19 November 2004 17:33: 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? This directory is only for scripts that are generally useful. Not for aircraft specific stuff. Look how the bo105 or the spitfire do it. In the *-set.xml file, there's a definition like this, which loads the nasal script: PropertyList ... nasal bo105 fileAircraft/bo105/Models/bo105.nas/file /bo105 /nasal /PropertyList ___ 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: Time to Refactor (was Re: [Flightgear-devel] Re: Nasal integration docs)
Andy Ross wrote: But here's a question on a related subject. How do we handle declaration of Nasal code? The ability to write inline handlers is great, but limited to small functions. The ability to drop module files into the Nasal directory is great too, for globally useful code. But sometimes you have non-trivial code that is nonetheless context-specific. The obvious example (as Melchior pointed out to me this morning) is per-aircraft scripts. We don't to have to drop a c172.nas file into the global namespace if we're flying a bo105. My answer to this issue this morning was this: I'm thinking about a property-space configuration, where you could do something like: nasal import module-namebo105/module-name source-filebo105.nas/source-file !-- Either a file -- !-- Or inline source code: -- script[CDATA[ ...nasal source code... ]]/script /import /nasal And the Nasal subsystem would then step through all the /nasal/import entries it found in the property tree and load the appropriate modules at initialization. I'm still a bit fuzzy this morning, but I want to point out that the current scheme of dropping in aircrafts by extracting them into their own directory should be preserved. The best way I can think of right now is setting property pointing to a directory in the aircraft-set.xml which nasal could check for the presence of .nas scripts. e.g. scripting-dirAircraft/bo105/Scripts/scripting-dir Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Time to Refactor (was Re: [Flightgear-devel] Re: Nasal integration docs)
Melchior FRANZ wrote: This and your examples (mouse handling, etc.) have totally won me over! I've already written my first nasal script I haven't had time to play with NASAL yet, but now that it's integrated and people seem to like it, it's probably time to start refactoring FlightGear a bit. Originally, I defined actions using XML mainly because we didn't have a scripting language, but ideally, we should share up the labour like this: XML = declarative NASAL = imperative i.e. if we want to say this is X, we use XML; if we want to say do Y, we use NASAL. A drop-down menu is declarative, but the actions associated with each menu item are imperative, and could be NASAL code snippits. The keymap is declarative, but the actions associated with each keystroke are imperative, and again, could be NASAL code snippits embedded in XML. If anyone wants to start on some analysis and make a few suggestions, or even rewrite some code, you have my blessing (as if you needed it). XML is a great language for serializing data structures, but it's a lousy syntax for writing code, and I've never liked using it that way. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Time to Refactor (was Re: [Flightgear-devel] Re: Nasal integration docs)
David Megginson wrote: Originally, I defined actions using XML mainly because we didn't have a scripting language, but ideally, we should share up the labour like this: XML = declarative NASAL = imperative Completely agree. Although it should be pointed out that there's significant gray area between the two extremes. Some of the existing commands (like property-adjust, with its handy wrap and clamp options) are simpler than the equivalent Nasal code for typical usages. Likewise, sometimes declaring your data in Nasal can save a lot of work interpreting that data on the C++ side. The mouse.nas sample was a good example of this. The whole idea of mouse mode cooked down to a literal object definition, where the methods were handlers for each event type. And the list of modes was simply a literal list dropped right there in the file. (Again, there's no point in replacing the mouse code, but if we were doing it from scratch...) But here's a question on a related subject. How do we handle declaration of Nasal code? The ability to write inline handlers is great, but limited to small functions. The ability to drop module files into the Nasal directory is great too, for globally useful code. But sometimes you have non-trivial code that is nonetheless context-specific. The obvious example (as Melchior pointed out to me this morning) is per-aircraft scripts. We don't to have to drop a c172.nas file into the global namespace if we're flying a bo105. My answer to this issue this morning was this: I'm thinking about a property-space configuration, where you could do something like: nasal import module-namebo105/module-name source-filebo105.nas/source-file !-- Either a file -- !-- Or inline source code: -- script[CDATA[ ...nasal source code... ]]/script /import /nasal And the Nasal subsystem would then step through all the /nasal/import entries it found in the property tree and load the appropriate modules at initialization. But unfortunately that doesn't work, because multiple definitions of the same property (/nasal/import, this case) from different files overwrite each other. I had been under the impression that they defined new indices (/nasal/import[1], etc...), but that only works from the same file. The requirement is basically that arbitrary PropertyList XML files be able to define Nasal code that will be found by the FGNasalSys object at initialization. I can see a few ways to do this, all ugly to differing degrees: + Hack at the SimGear property parser to understand the FlightGear (!) nasal subsystem and invoke the (Nasal) parser at (XML) parse time. No. :) + Hack at the property parser to support the add index behavior across files. Less ugly, but this might (probably will) break existing usage that expects to override the global property instead. + Write initialization code to walk through the entire property tree looking for nasal-import nodes. This isn't so bad to implement, and is easy to understand, but walking the tree just seems icky. It's also a mild encapsulation violation, since sub-trees might want control over their own nodes' interpretation. + Use a /nasal/unique-name convention instead. Then the FGNasalSys::init() method simply iterates over all the children of /nasal, instead of all the indices of /nasal/import. The only trick here is coming up with a truly unique name, which is trivial for the case of aircraft definitions (just use the aircraft name). This is probably cleanest. But it does have the disadvantage that only property files at the root of the property tree can define nasal code. The tree walker mechanism above works anywhere. Anyway, I thought I'd throw that out to the list before I start trying to code something. There just doesn't seem to be an obvious Right Thing for this problem. For the record, neither of the two latter solutions will be hard to implement. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
