Re: [Flightgear-devel] Nasal - Question
Vivian Meazza wrote: I have hit a snag while writing some Nasal script for the Spitfire model: I put this in the spitfireIIa-set.xml file controls engines engine n=0 magneto-switch type=bool1/magneto-switch magneto-switch type=bool1/magneto-switch /engine /engines /controls I then try to access it elsewhere. This works: binding commandnasal/command script setprop(controls/engines/engine/magneto-switch[0],1); /script /binding But this doesn't: binding commandnasal/command script setprop(controls/engines/engine/magneto-switch[1],1); /script /binding I can work around it no problem, but I think that it should work. I can see, but can't access ../magneto-switch[1] in the Browse Internal Properties dialog either. I think that it may be a property tree issue rather than Nasal. Any guidance/ideas? Does your spitfire have more than one magneto switch? This generally implies more than one engine. The value of the first magneto-switch[0] is probably what you want to be changing. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal - Question
Curtis L. Olson wrote: Vivian Meazza wrote: I have hit a snag while writing some Nasal script for the Spitfire model: I put this in the spitfireIIa-set.xml file controls enginesengine n=0 magneto-switch type=bool1/magneto-switch magneto-switch type=bool1/magneto-switch /engine /engines /controls I then try to access it elsewhere. This works: binding commandnasal/command script setprop(controls/engines/engine/magneto-switch[0],1); /script /binding But this doesn't: binding commandnasal/command script setprop(controls/engines/engine/magneto-switch[1],1); /script /binding I can work around it no problem, but I think that it should work. I can see, but can't access ../magneto-switch[1] in the Browse Internal Properties dialog either. I think that it may be a property tree issue rather than Nasal. Any guidance/ideas? Does your spitfire have more than one magneto switch? This generally implies more than one engine. The value of the first magneto-switch[0] is probably what you want to be changing. Regards, Curt. I thought most piston planes had two magnetos per engine ... Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal - Question
Josh Babcock wrote: Curtis L. Olson wrote: Vivian Meazza wrote: I have hit a snag while writing some Nasal script for the Spitfire model: I put this in the spitfireIIa-set.xml file controls enginesengine n=0 magneto-switch type=bool1/magneto-switch magneto-switch type=bool1/magneto-switch /engine /engines /controls I then try to access it elsewhere. This works: binding commandnasal/command script setprop(controls/engines/engine/magneto-switch[0],1); /script /binding But this doesn't: binding commandnasal/command script setprop(controls/engines/engine/magneto-switch[1],1); /script /binding I can work around it no problem, but I think that it should work. I can see, but can't access ../magneto-switch[1] in the Browse Internal Properties dialog either. I think that it may be a property tree issue rather than Nasal. Any guidance/ideas? Does your spitfire have more than one magneto switch? This generally implies more than one engine. The value of the first magneto-switch[0] is probably what you want to be changing. Regards, Curt. I thought most piston planes had two magnetos per engine ... Right, but the aircraft I have seen have just one *switch* ... off, both, left, right (and sometimes starter power is rolled in too.) If the physical aircraft has a separate switch for each magneto, then the underlying logic should just change the magneto-switch[0] value. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Nasal - Question
Curtis L. Olson Josh Babcock wrote: Curtis L. Olson wrote: Vivian Meazza wrote: I have hit a snag while writing some Nasal script for the Spitfire model: I put this in the spitfireIIa-set.xml file controls enginesengine n=0 magneto-switch type=bool1/magneto-switch magneto-switch type=bool1/magneto-switch /engine /engines /controls I then try to access it elsewhere. This works: binding commandnasal/command script setprop(controls/engines/engine/magneto-switch[0],1); /script /binding But this doesn't: binding commandnasal/command script setprop(controls/engines/engine/magneto-switch[1],1); /script /binding I can work around it no problem, but I think that it should work. I can see, but can't access ../magneto-switch[1] in the Browse Internal Properties dialog either. I think that it may be a property tree issue rather than Nasal. Any guidance/ideas? Does your spitfire have more than one magneto switch? This generally implies more than one engine. The value of the first magneto-switch[0] is probably what you want to be changing. Regards, Curt. I thought most piston planes had two magnetos per engine ... Right, but the aircraft I have seen have just one *switch* ... off, both, left, right (and sometimes starter power is rolled in too.) If the physical aircraft has a separate switch for each magneto, then the underlying logic should just change the magneto-switch[0] value. Regards, Curt. The physical aircraft has 2 magnetos and two switches, and a separate starter (a Coffman cartridge starter - but that's a longer term problem). I know that the magneto property has values 0,1,2,3 but my solution was to model the switches first - I have (had) a cunning plan. But that's not really the question - I can work around the problem - but why doesn't the script work? V. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal - Question
Vivian Meazza wrote: Curtis L. Olson wrote: Right, but the aircraft I have seen have just one *switch* ... off, both, left, right (and sometimes starter power is rolled in too.) If the physical aircraft has a separate switch for each magneto, then the underlying logic should just change the magneto-switch[0] value. The physical aircraft has 2 magnetos and two switches, and a separate starter (a Coffman cartridge starter - but that's a longer term problem). Actually, it might be cleaneast to model the engine control properties as something like: /engines/engine[n]/magneto[0] (boolean) /engines/engine[n]/magneto[1] (boolean) /engines/engine[n]/starter(boolean) And re-write the standard switch binding such that it sets the appropriate booleans on the engines based on the 4 switch position values. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal - Question
Vivian Meazza wrote: This works: setprop(controls/engines/engine/magneto-switch[0],1); But this doesn't: setprop(controls/engines/engine/magneto-switch[1],1); I can work around it no problem, but I think that it should work. I can see, but can't access ../magneto-switch[1] in the Browse Internal Properties dialog either. I think that it may be a property tree issue rather than Nasal. Any guidance/ideas? I dunno, this all looks correct to me, both the Nasal and the XML definitions. The fact that you can't read it in the browser is especially weird. Maybe there's a tie or an alias that's getting in the way? Try binding a key to do: props.dump(props.globals.getNode(/controls/engines/engine)); And see what you find. This will crawl the specified property tree and recursively dump all the sub-properties, with their types. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal - Question
Andy Ross wrote: Actually, it might be cleaneast to model the engine control properties as something like: /engines/engine[n]/magneto[0] (boolean) /engines/engine[n]/magneto[1] (boolean) /engines/engine[n]/starter(boolean) And re-write the standard switch binding such that it sets the appropriate booleans on the engines based on the 4 switch position values. I agree. Some older planes do have the starter separate from the magneto switch. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Nasal - Question
Andy Ross wrote Sent: 17 June 2004 19:36 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Nasal - Question Vivian Meazza wrote: Curtis L. Olson wrote: Right, but the aircraft I have seen have just one *switch* ... off, both, left, right (and sometimes starter power is rolled in too.) If the physical aircraft has a separate switch for each magneto, then the underlying logic should just change the magneto-switch[0] value. The physical aircraft has 2 magnetos and two switches, and a separate starter (a Coffman cartridge starter - but that's a longer term problem). Actually, it might be cleaneast to model the engine control properties as something like: /engines/engine[n]/magneto[0] (boolean) /engines/engine[n]/magneto[1] (boolean) /engines/engine[n]/starter(boolean) And re-write the standard switch binding such that it sets the appropriate booleans on the engines based on the 4 switch position values. Hah! You have sussed out the cunning plan ... Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Nasal - Question
Andy Ross advised Sent: 17 June 2004 19:32 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Nasal - Question Vivian Meazza wrote: This works: setprop(controls/engines/engine/magneto-switch[0],1); But this doesn't: setprop(controls/engines/engine/magneto-switch[1],1); I can work around it no problem, but I think that it should work. I can see, but can't access ../magneto-switch[1] in the Browse Internal Properties dialog either. I think that it may be a property tree issue rather than Nasal. Any guidance/ideas? I dunno, this all looks correct to me, both the Nasal and the XML definitions. The fact that you can't read it in the browser is especially weird. Maybe there's a tie or an alias that's getting in the way? Try binding a key to do: props.dump(props.globals.getNode(/controls/engines/engine)); And see what you find. This will crawl the specified property tree and recursively dump all the sub-properties, with their types. Done that - all looks as it should. ../magneto-switch[1]is not set here either. However, a new fact that I hadn't noticed before, is that when accessing ../magneto-switch[1] through the Browse Internal Properties dialog it sets ../magneto-switch[0]. Weird or what? Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal question
David Culp wrote:
The problem is that the script is executed while the aircraft's
heading is still zero, prior to it being oriented with the runway. Is
there a way to have the script execute only after the aircraft is
aligned with the runway?
As an immediate hack, you can set it up to run after a timeout.
Something like this will work:
SRCPROP = /orientation/heading-magnetic-deg;
DSTPROP = /autopilot/settings/heading-bug-deg;
DELAY = 1;
settimer(func { setprop(SRCPROP, getprop(DSTPROP)) }, DELAY);
You will probably need to experiment to find a value of DELAY that
works on all systems. What is *really* needed here is a way to tell
when initialization is done, and hook in a callback for that. Right
now the various subsystems finish their work at different times, which
causes problems like this one.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal question
settimer(func { setprop(SRCPROP, getprop(DSTPROP)) }, DELAY);
Thanks Andy, six seconds works well for me, which seems like a lot. I wonder
how much variation there is among users. It would be nice if we had a
standard nasal script, init-complete.nas, that is called after everything
else initializes.
Dave
--
David Culp
davidculp2[at]comcast.net
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal question
Josh Babcock wrote: I tried propertySlew() but it seems that the value wasn't going to the numbers I supplied, but only slewing for a very short period of time taht wasn't even consistant. You need to mark the bindings repeatable. See the trim bindings for examples. The propertySlew() function slews a property by the appropriate amount for the current frame only (based on the time it took to render the last frame). If you only call it once when the button is pressed/released, you will only get one frame of motion. The time will look inconsistant because individual frames take varying times to render. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal question
Andy Ross wrote: SNIP You need to mark the bindings repeatable. See the trim bindings for examples. Whoops. Typo, or cut-and-past-o I guess. That's what you get for coding with the flu I. Now the brakes go on like I want, but I have the same problem with them coming off. Apparently repeatable tags don't affect anything inside a mod-up tag. In retrospect, this makes a lot of sense. For this will I have to implement something like the flaps using stepProp? If so, will I have to make changes outside of the joystick file to define a hash for nasal? Is there a utility function to move a property from value a to value b over a given delta? I looked but didn't see anything that said it would do that. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal question
Never mind. I just remembered interpolate. This works perfectly. Josh button n=1 descLeft Brake/desc repeatable type=booltrue/repeatable binding commandnasal/command scriptinterpolate(/controls/gear/brake-left, props.globals.getNode(/controls/gear/brake-left).getValue(), 0, 1, 0.1)/script /binding mod-up repeatable type=booltrue/repeatable binding commandnasal/command scriptinterpolate(/controls/gear/brake-left, props.globals.getNode(/controls/gear/brake-left).getValue(), 0, 0, 0.1)/script /binding /mod-up /button ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal question
Some quick suggestions: You wrote: interpolate(/controls/gear/brake-left, props.globals.getNode(/controls/gear/brake-left).getValue(), 0, 1, 0.1) Actually, the implementation of interpolate() always starts from the current value of a property, so in fact there's no need for the first two arguements. This call should have the same effect: interpolate(/controls/gear/brake-left, target-value, 0.1) And a more general note: the getValue() expression can be more simply (and efficiantly, for that matter) written as: getprop(/controls/gear/brake-left) The props.Node interface is there for completeness and flexibility, but grabbing constant strings out of the the property tree is best done with the simple API. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
