Re: [Flightgear-devel] Understanding the design of aircraft nasal scripts
On 04/08/2011 10:40 PM, Catherine James wrote: Recently, I've been spending a good bit of time attempting to program all of my most-used aircraft so that I can engage and disengage the autopilot through the joystick. I've been able to get this to work on the Seneca II with a short nasal script in Nasal/SenecaII.nasal that sets the /autopilot/CENTURYIII/controls and /autopilot/CENTURYIII/locks properties appropriately. Silly me, I though it would be a simple matter to port the working code over to the Comanche PA-24-250 (w/ CIII autopilot). Unfortunately, the structure of the nasal scripts of the PA24 bears very little resemblance to that of the Seneca II. Although the relevant autopilot properties are the same for both planes, the flow of control is not. For example, turning on the autopilot roll axis control with the plane on the ground is harmless in the Seneca, but will cause a nasal crash in the (stock, unmodified) Comanche, and turning the autopilot off again will not recover. (The ailerons will be locked permanently at 0 until you restart.) The routine that crashes is action-sim.nas, a file that doesn't even exist in the Seneca. It contains an update_actions() script that is looped repeatedly, updating positions of control surfaces, etc. With the autopilot on, the script attempts to get the appropriate aileron position from the autopilot, but it returns null and then cause a setValue() error when it blindly tries to set the actual aileron position to that null. The same thing happens if I turn on the autopilot in flight by using the joystick to change the /autopilot/CENTURYIII/controls properties through a script. Is there a general file and scripting structure that it is recommended to follow for implementing aircraft? It's very challenging to learn to understand and modify aircraft implementations when the general arrangement of files is so different from one to the next. How are you turning on the roll axis and how are you turning off the autopilot. I just tried to reproduce your failures and did not have the problems you describe. I am the author of the pa24-250. The model assumes that you are using the switches via the picks. The nasal code replicates the behavior described in the Century III Autopilot Flight System Pilot's Operating Handbook. You used to be able to download a PDF of this from Century. This is no longer the case. There are logical relations between the four switches that are included in the model. If you are changing the locks outside the Nasal models, you will most likely create a state that is not possible via the model code and also not accurate according to the referenced manual. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Understanding the design of aircraft nasal scripts
The nasal code replicates the behavior described in the Century III Autopilot Flight System Pilot's Operating Handbook. You used to be able to download a PDF of this from Century. This is no longer the case. Try this link http://www.centuryflight.com/manuals/CENTIIB.pdf. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Understanding the design of aircraft nasal scripts
Catherine, Not quite the answer you seek, but following to Sids comments. My advice is keep any thing you want generic to your setup away from aircraft model nasal if possible. If it helps, I used xml for controlling some auto pilot functions via Joy stick control to avoid fooling around in nasal. I have attached the xml file for you as info. Some notes that should be in the file: The file is based on commands given to execute button presses in the 737 autopilot panel xml file. The trigger on button 0 is used as a shift function so the top hat left to right moves the heading, then shifted moves the course. Likewise un-shifted one of the buttons selects heading mode and shifted selects vor mode. I ran it inconjuction with the older 2d AP panel in the 2005 era 737-300 model, I am not sure about the new 3d panels. However its not panel dependent, it drives the autopilot setting and lock properties directly. and runs ok againt the current v4.5 737 series autopilot xml implementation or the basic generic FG autopilot on the current FG git version. I think it would run ok against any model, but would not promise it as i only use the 737 implementations. As far as I recall there are no funnies in it unique to my sim setup. Harry On Sat, Apr 9, 2011 at 12:10 PM, syd adams adams@gmail.com wrote: Maybe you already looked into this , but to me it would make more sense to bind the joystick buttons to activate the enable properties in the actual autopilot.xml files rather than modifying the author's specialized scripts.Or write a generic nasal file to handle the variety of different enabling methods ? The autopilot xml file does the real work , but enabling a mode can be set with pretty much any property or condition the author decides on ,so that could be a large chore.Most extra nasal code was written for a reason , mainly to make the autopilot behave like the real one , so modifying that might be tricky.Just my thoughts, if you,ve already discovered all that , i apologize for the noise. Cheers On Fri, Apr 8, 2011 at 10:40 PM, Catherine James catherine.ja...@att.net wrote: Recently, I've been spending a good bit of time attempting to program all of my most-used aircraft so that I can engage and disengage the autopilot through the joystick. I've been able to get this to work on the Seneca II with a short nasal script in Nasal/SenecaII.nasal that sets the /autopilot/CENTURYIII/controls and /autopilot/CENTURYIII/locks properties appropriately. Silly me, I though it would be a simple matter to port the working code over to the Comanche PA-24-250 (w/ CIII autopilot). Unfortunately, the structure of the nasal scripts of the PA24 bears very little resemblance to that of the Seneca II. Although the relevant autopilot properties are the same for both planes, the flow of control is not. For example, turning on the autopilot roll axis control with the plane on the ground is harmless in the Seneca, but will cause a nasal crash in the (stock, unmodified) Comanche, and turning the autopilot off again will not recover. (The ailerons will be locked permanently at 0 until you restart.) The routine that crashes is action-sim.nas, a file that doesn't even exist in the Seneca. It contains an update_actions() script that is looped repeatedly, updating positions of control surfaces, etc. With the autopilot on, the script attempts to get the appropriate aileron position from the autopilot, but it returns null and then cause a setValue() error when it blindly tries to set the actual aileron position to that null. The same thing happens if I turn on the autopilot in flight by using the joystick to change the /autopilot/CENTURYIII/controls properties through a script. Is there a general file and scripting structure that it is recommended to follow for implementing aircraft? It's very challenging to learn to understand and modify aircraft implementations when the general arrangement of files is so different from one to the next. -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Regards Harry ?xml version=1.0 ? !--
Re: [Flightgear-devel] Understanding the design of aircraft nasal scripts
Sid wrote: Maybe you already looked into this , but to me it would make more sense to bind the joystick buttons to activate the enable properties in the actual autopilot.xml files rather than modifying the author's specialized scripts.Or write a generic nasal file to handle the variety of different enabling methods? This is the path I was hoping to take, but I haven't found out a good way to handle issues that differ from one plane to another. For example, in the Seneca, the key properties are autopilot/CENTURYIII/controls/x and /autopilot/CENTURYIII/locks/y, where x and y are pitch-hold, roll-axis, etc. But in the B1900, the key properties are /autopilot/locks/yaw-damper and /autopilot/locks/passive-mode, which don't exist in the Seneca. For the Comanche w/ Century III, I haven't found a set of properties that work correctly when triggered through joystick xml. How can a script that does not have aircraft-specific versions handle them all? The best approach I've come up with so far is to have the joystick xml file call controls.autopilotEngage() and controls.autopilotDisengage(), put a generic version of the engage and disengage scripts into $FG_ROOT/Nasal/controls.nas, and override this function for aircraft that need to modify it. In effect I'm using object-oriented inheritance, overriding the method in the Aircraft nasal from the pseudo-base-class in the root. The hidden agenda to all this is that it gives me an excuse to figure out how Nasal works. :-) Thoughts welcome -- you guys are the experienced developers. Cathy -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Understanding the design of aircraft nasal scripts
Just another thought , but I'm on a laptop with mouse ... no joystick to test is property aliasing ? the multipayer options give me the idea but i'm no expert on this myself... multiplay generic int n=0 alias=/systems/electrical/outputs/strobe/ /generic /multiplay This is an example is a property transmitted over MP. Mind you , you'd have to add a section to each aircraft set file maybe not such a great idea after all. Also , this doesn't help with learning nasal , so feel free to ignore it ;) . Just tossing out ideas . Cheers -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Understanding the design of aircraft nasal scripts
Maybe you already looked into this , but to me it would make more sense to bind the joystick buttons to activate the enable properties in the actual autopilot.xml files rather than modifying the author's specialized scripts.Or write a generic nasal file to handle the variety of different enabling methods ? The autopilot xml file does the real work , but enabling a mode can be set with pretty much any property or condition the author decides on ,so that could be a large chore.Most extra nasal code was written for a reason , mainly to make the autopilot behave like the real one , so modifying that might be tricky.Just my thoughts, if you,ve already discovered all that , i apologize for the noise. Cheers On Fri, Apr 8, 2011 at 10:40 PM, Catherine James catherine.ja...@att.net wrote: Recently, I've been spending a good bit of time attempting to program all of my most-used aircraft so that I can engage and disengage the autopilot through the joystick. I've been able to get this to work on the Seneca II with a short nasal script in Nasal/SenecaII.nasal that sets the /autopilot/CENTURYIII/controls and /autopilot/CENTURYIII/locks properties appropriately. Silly me, I though it would be a simple matter to port the working code over to the Comanche PA-24-250 (w/ CIII autopilot). Unfortunately, the structure of the nasal scripts of the PA24 bears very little resemblance to that of the Seneca II. Although the relevant autopilot properties are the same for both planes, the flow of control is not. For example, turning on the autopilot roll axis control with the plane on the ground is harmless in the Seneca, but will cause a nasal crash in the (stock, unmodified) Comanche, and turning the autopilot off again will not recover. (The ailerons will be locked permanently at 0 until you restart.) The routine that crashes is action-sim.nas, a file that doesn't even exist in the Seneca. It contains an update_actions() script that is looped repeatedly, updating positions of control surfaces, etc. With the autopilot on, the script attempts to get the appropriate aileron position from the autopilot, but it returns null and then cause a setValue() error when it blindly tries to set the actual aileron position to that null. The same thing happens if I turn on the autopilot in flight by using the joystick to change the /autopilot/CENTURYIII/controls properties through a script. Is there a general file and scripting structure that it is recommended to follow for implementing aircraft? It's very challenging to learn to understand and modify aircraft implementations when the general arrangement of files is so different from one to the next. -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
