Hi everybody,mainly who is expert in xml of FlightGear.Is there any way to set a property outside a binding, or at least, a way to bind a property assign inside a layer definition or inside another type of tags?I am making some modifications and improvements to B-737, mainly in the autopilot procedures, flaps and landing gear routines. The standby-ah is already done and running. Flaps in transit is already done OK. Landing gear lever up and down already is OK. Despite the fact I am not a pilot, at moment I am programming all routines of AFDS as result of sparse and rare documentation I found here on net. The MCP panel is already implementing all most important modes, including CWS and CMD. The coding is flowing with the disponibility of time.The case is: Master caution light needs annunciate, for instance, that gear is still up while aircraft is below 800 ft RA and not climbing, of course. This situations must reflects also on the audible alarm. I wish create a property (already is created when gear red lights are turned to red to annunciate the fact) that can be assigned as true whenever that situation is encountered, and this property would drive decisions over panel texture of master caution and turn-on alarm. By now, the peace of logic is repeated in the gear lights, master caution and sounds XMl parts, but i would like to optimize these.When i finish all modifications and improvements I am making, they will be OK to Flightgear community. I am a declared volunteer.Geer!!!

>Hi everybody,>>mainly who is expert in xml of FlightGear.>>Is there any way to set a property outside a binding, I'm not sure I understand you correctly, but if you want a certain property to be set at startup, preferences.xml under $FG_ROOT would be suitable. However, any properties set in preferences.xml should either be applicable globally or contain defaults that may be overriden on an individual basis by certain aircraft.>or at least, a way to bind a property assign inside a layer>definition or inside another type of tags?Well, I don't think you can currently manipulate properties from within the instrument animation XML files, while this would be pretty straight forward to implement (only about 10 additional lines of C++ code), I suppose that you might as well simply use some simple nasal source code to achieve what you want to do.For example, something like the following:#------------------------------------------------------------------------------------#sample.nas:#callback function named check:check = func { #you will want to modify the property path below: path="/path/to/my/property"; value=getprop(path); #this will check the value and print a message to the console if 'true' if (value=="true") { print("value is true"); }}#now register a timer to call the callback:settimer(check,1);#---sample.nas#------------------------------------------------------------------------------------>I am making some modifications and improvements to B-737,>mainly in the autopilot procedures, flaps and landing gear>routines. The standby-ah is already done and running. Flaps in>transit is already done OK. Landing gear lever up and down>already is OK. Despite the fact I am not a pilot, at moment I>am programming all routines of AFDS as result of sparse and>rare documentation I found here on net. The MCP panel is>already implementing all most important modes, including CWS>and CMD. The coding is flowing with the disponibility of>time.>>The case is: Master caution light needs annunciate, for>instance, that gear is still up while aircraft is below 800 ft>RA and not climbing, of course. This situations must reflects>also on the audible alarm. I wish create a property (already>is created when gear red lights are turned to red to>annunciate the fact) that can be assigned as true whenever>that situation is encountered, and this property would drive>decisions over panel texture of master caution and turn-on>alarm. By now, the peace of logic is repeated in the gear>lights, master caution and sounds XMl parts, but i would like>to optimize these.If I understand you correctly, you are attempting to centralize all logics in one place, so that there's only one piece of code that's responsible for the logics?In that case, I'd personally really recommend to look into Nasal coding, "Nasal" is FlightGear's scripting language and it should be quite possible to achieve your goals using Nasal, even though you might have to add a couple of hooks here and there, or have someone else add these "hooks" for you. Basically, you could then have one function that's triggered by a timer (or possibly also on a per frame basis) to poll all relevant properties and check for their values (check above example).Given your description, I'm pretty sure that the people subscribed to the FlightGear Devel mailing list would not only be interested in your improvements, but also quite willing to help implementing your ideas. Also, there are meanwhile several good "hands on" examples about how to use Nasal in FlightGear available, just check $FG_ROOT/Nasal, $FG_ROOT/Aircraft and the mailing list archives (search for "NASAL").It's probably a good idea to think about a scripted approach anyway, as most of the pseudo-logic constructs supported by SGCondition, (i.e. , etc.) are relatively crude and were probably really only meant to be a compromise until scripting capabilities were added to FlightGear.Hence, now that scripting support is available in FlightGear, XML encoded logics are pretty much obsolete meanwhile and you can expect FlightGear to eventually concentrate on using its scripting language Nasal whereever feasible.Also, it's going to be much easier to implement more advanced logics using a scripting language (i.e. think about a FMS), rather than using huge XML encoded PropertyLists. You may want to search the mailing list archives for postings concerning the implementation of the electrical system, initially this was also hard-coded but has now been superceeded by a Nasal based implementation, which makes things much more maintainable and thus extendable.

Hello hfitz,thanks for reply, and sorry for delay (I was out, tripping).OK, the case is (also) centralize a piece of programming logic, and C++ or even Nasal will do the things. But the real difficulty is to bind a without have a human over a panel. When some event is occurring (automactically) during a fly, like we forget gear-down during a landing, some piece of logic must be created to bind a property value accordingly to that event, that doesn

Hello hfitz,thanks for reply, and sorry for delay (I was out, tripping).OK, the case is (also) centralize a piece of programming logic, and C++ or even Nasal will do the things. But the real difficulty is to bind a without have a human over a panel. When some event is occurring (automactically) during a fly, like we forget gear-down during a landing, some piece of logic must be created to bind a property value accordingly to that event, that doesn

Hello hfitz,thanks for reply, and sorry for delay (I was out, tripping).OK, the case is (also) centralize a piece of programming logic, and C++ or even Nasal will do the things. But the real difficulty is to bind a without have a human over a panel. When some event is occurring (automactically) during a fly, like we forget gear-down during a landing, some piece of logic must be created to bind a property value accordingly to that event, that doesn

>OK, the case is (also) centralize a piece of programming>logic, and C++ or even Nasal will do the things. But the real>difficulty is to bind a without have a human> over a panel. When some event is occurring>(automactically) during a fly, like we forget gear-down during>a landing, some piece of logic must be created to bind a>property value accordingly to that event, that doesn

>Hello hfitz,>>thanks for reply, and sorry for delay (I was out, tripping).no problem, everything here is volunteer based, so nobody should be surprised about delays at all.>OK, the case is (also) centralize a piece of programming>logic, and C++ or even Nasal will do the things. I see>But the real>difficulty is to bind a without have a human> over a panel. I suggested the scripted approach because you could basically use timers to implement something like this easily.> When some event is occurring>(automactically) during a fly, like we forget gear-down during>a landing, some piece of logic must be created to bind a>property value accordingly to that event, that doesn

>OK, the case is (also) centralize a piece of programming>logic, and C++ or even Nasal will do the things. But the real>difficulty is to bind a without have a human> over a panel.Sorry, just re-read and actually understood what you were saying:If you are referring to the XML files, you can simply make up your own property node in the corresponding condition, i.e. such as:/sim/assumed-landingas long as it's not true, the transformation, sound or whatever action won't be triggered, however when your nasal script actually does come to the conclusion that you are trying to land (based on the previously outlined indicators) it can easily do something such as:setprop("/sim/assumed-landing",true);Hence, anything that might depend on your aircraft trying to land, would then automatically also be checked.So, you will probably want to look into the implementation of XML based instruments, given that these also update based on property nodes, without requiring human interaction for the update, you can see how it's done.Also, you may want to consider subscribing to the FlightGear Devel mailing list, as there are plenty of people who would probably be more than willing to help you with your work.In the end, it will be up to you what level of fidelity you model, because you can basically get as complex as you want if you use a scripted approach.However, really make sure to first play around with Nasal a bit, so that you don't make things unnecessarily complex, because it could really be as simple as doing (pseudo code):checkApproach=func {condition1=getprop("......");condition2=getprop("......");condition3=getprop("......");#check if all conditions imply an approach being in progresssetprop("/sim/assumed-landing",true);}