Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
* Durk Talsma -- Wednesday 21 September 2011: > 1). Is there a 1 to 1 correspondence between the value of the /sim/aircraft > property and the name of the xml file where aircraft specific properties will > be saved in? Yes. The path is generated in aircraft.data.init ($FG_ROOT/Nasal/aircraft.nas:348): me.path = getprop("/sim/fg-home") ~ "/aircraft-data/" ~ getprop("/sim/aircraft") ~ ".xml"; > 2). Is there a command line option to specifically tell FlightGear which > livery should be loaded? No, the organization of the liveries (paths and properties) is left to the aircraft. Of course, one could easily standardize that and make it settable at least with --prop:sim/... m. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
On 21 Sep 2011, at 11:12, Melchior FRANZ wrote: > > > > /sim/dimensions/radius-m > /sim/dimensions/parkpos-offset-m > /sim/aircraft-class > > > Alright succes!!! Adding this section did the trick of saving aircraft-class and aircraft-operator properties, after they were were changed by the livery select mechanism. But, then my trouble wasn't over yet: It turned out the data from fghome/aircraft-data/[aircraft].xml haven't been processed yet, at the time fgInitialPosition is called. But it looks like I can work around this by prefetching this file. reading it into a local property tree and fetching the data from there. The code needs some more cleaning up, and I have two additional questions: 1). Is there a 1 to 1 correspondence between the value of the /sim/aircraft property and the name of the xml file where aircraft specific properties will be saved in? 2). Is there a command line option to specifically tell FlightGear which livery should be loaded? cheers, Durk P.S., Muchos gracias to Melchior and Torsten for pointing me in the right direction! D. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
* Melchior FRANZ -- Wednesday 21 September 2011: > "userarchive" simply marks what gets written to $FG_HOME/preferences.xml Whoops ... to $FG_HOME/autosave.xml. (preferences.xml was used first, but a bad idea and changed later.) m. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
* Durk Talsma -- Wednesday 21 September 2011: > Just a quick question: Is this documented somewhere? Don't think so. Only in the code, that is. > If not, I might start a short wiki page documenting the logic behind > "archieve", "userarchieve", and the interactions with the nasal system. "userarchive" simply marks what gets written to $FG_HOME/preferences.xml and loaded next time from there (if and only if /sim/startup/save-on-exit is true). It's mainly thought for persistent GUI settings. It should not be set by aircraft, *ever*. (Needless to say that some aircraft do it anyway.[0]) "archive" is used by simgear/props_io.cxx -> writeProperties(). This function either saves a whole property tree or only those properties with set "archive" flag. This is used by fgSaveFlight(), which should only save the properties that are to be restored when a saved flight is loaded again via menu. This was broken for so long, until everyone had forgotten what "archive" was about and on which properties it should be set. It's basically what ac_state.nas does in pure Nasal, once again ... m. [0] 727-230 737-300 777-200 787 ATC B-1B CRJ-200 MPCarrier OV10 Rascal SenecaII bf109 ch53e dhc8 spitfireIX -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
Hi Mechior, Torsten On 21 Sep 2011, at 12:57, Melchior FRANZ wrote: > * Melchior FRANZ -- Wednesday 21 September 2011: >> >> >> /sim/dimensions/radius-m > > I admit that this looks silly: why create properties that contain property > paths, > and not mark those properties with a flag right away, like with "archive" and > "userarchive"? > Thanks for your explanation; I feel like I have a much better idea what is going on and at least have a few other things to try tonight. Just a quick question: Is this documented somewhere? If not, I might start a short wiki page documenting the logic behind "archieve", "userarchieve", and the interactions with the nasal system. cheers, Durk -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
* Melchior FRANZ -- Wednesday 21 September 2011: > > > /sim/dimensions/radius-m I admit that this looks silly: why create properties that contain property paths, and not mark those properties with a flag right away, like with "archive" and "userarchive"? The reasons why I did it this way were: properties should be add-able from Nasal (setting property flags wasn't possible back then), introducing a new flag didn't seem desirable (simgear was still considered a generic library, much more than it seems to be nowadays), scanning the whole tree for just a few flags seemed undesirable, doing it in pure Nasal a quick and easy solution, and only very few aircraft needed it. Nowadays I'd probably go for proper flags. Ideally, their XML names shouldn't be hard-coded in simgear, but settable at initialization time. aircraft.data.add() could then be changed to just set that flag (props.Node.setAttribute(...)). m. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
> Or just: > > > >/sim/dimensions/radius-m >/sim/dimensions/parkpos-offset-m >/sim/aircraft-class > > > > from where it's read by aircraft.nas already. Excellent! I'm learning something new every day... > But then again: static aircraft data like radius and class shouldn't > be saved that way *at all*. It belongs to *-set.xml, and possibly to > a block in the animation xml file (see AAR). Good point. Torsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
* Torsten Dreyer -- Wednesday 21 September 2011: > > >
Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
No it wouldn't interfere because it wouldn't get executed unless you explicitly add it to the *-set.xml's section. Either as a link to a *.nas file or coded inline like this: ... To add this globally for all aircraft, probably $FGDATA/Nasal/aircraft.nas would be a good place for this code. Torsten Am 21.09.2011 09:03, schrieb Durk Talsma: > Hi Torsten, > > I looked at your seneca file, briefly, but didn't really find a way to > translate this to the 777 sittuation. Being a complete nasal newbie, can I > just add this function to any existing nasal script, or could I even put this > code into a new file? Say I'm creating a new nasal file called > "acopsdata.nas" containing: > > aircraft.data.add( > "/sim/dimensions/radius-m", > "/sim/dimensions/parkpos-offset-m", > "/sim/aircraft-class", > " /sim/aircraft-operator" > ); > > and copy that to the SenecaII nasal directory, would that interfere with your > existing nasal code? > > Cheers, > Durk > > On 20 Sep 2011, at 23:07, Torsten Dreyer wrote: > >> Am 20.09.2011 22:25, schrieb Durk Talsma: >>> how I can specify new property in an aircraft -set.xml file, and ensure >>> that any changes to this property are saved in an aircraft specific data >>> file. >> >> Just add this to you aircraft's nasal code so it gets executed once >> during startup. >> >> aircraft.data.add( >>"/one/property", >>"/another/property", >>"/and/another/property" >> ); >> >> Torsten >> >> -- >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2dcopy1 >> ___ >> Flightgear-devel mailing list >> Flightgear-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > -- > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
hi Emilian, On 20 Sep 2011, at 22:56, Emilian Huminiuc wrote: >> > Adding archive="y" to the property tag?: > myprop > That's how I thought it should work, but I don't get this to work. After some more experimentation, I found that I can save the property using userarchive="y", into autosave.xml. But using "archive" doesn't seem to work. My hypothesis is that "userarchive" save a property globally, whereas "archive" saves it into the local, aircraft specific (.fgfs/aircraft-data/777-200ER.xml) file. But,I couldn't find these properties anywhere. Incidentally, I did find a few "interesting things". Taking /sim/aircraft-operaror as an example, I added: NONE to the 777-200ER-set.xml file, and added DAL KLM BAW To the DAL, KLM, and BAW .xml fles in Models/Liveries, assuming that these would override the values of the already existing properties. However that's not what happens: This way the property value does not get saved, presumably because it destroys the original property object and replaces it with a new one that doesn't carry the "userarchive" flag. Is that correct? After adding the "userarchive" flag, to the properties in the Livery xml files, I found that they were saved again. Finally, I would be perfectly happy to just use the value stored in the livery xml file, but the problem here is that the aircraft model is only read AFTER the initial position has been calculated. At that point, the property is still set to the default value of NONE, which essentially makes it useless. If there would be other ways to retrieve a property from the currently selected livery xml file that I would also be interested in hearing that. So close, yet so far away... cheers, Durk -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
Hi Torsten, I looked at your seneca file, briefly, but didn't really find a way to translate this to the 777 sittuation. Being a complete nasal newbie, can I just add this function to any existing nasal script, or could I even put this code into a new file? Say I'm creating a new nasal file called "acopsdata.nas" containing: aircraft.data.add( "/sim/dimensions/radius-m", "/sim/dimensions/parkpos-offset-m", "/sim/aircraft-class", " /sim/aircraft-operator" ); and copy that to the SenecaII nasal directory, would that interfere with your existing nasal code? Cheers, Durk On 20 Sep 2011, at 23:07, Torsten Dreyer wrote: > Am 20.09.2011 22:25, schrieb Durk Talsma: >> how I can specify new property in an aircraft -set.xml file, and ensure that >> any changes to this property are saved in an aircraft specific data file. > > Just add this to you aircraft's nasal code so it gets executed once > during startup. > > aircraft.data.add( > "/one/property", > "/another/property", > "/and/another/property" > ); > > Torsten > > -- > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
Am 20.09.2011 22:25, schrieb Durk Talsma: > how I can specify new property in an aircraft -set.xml file, and ensure that > any changes to this property are saved in an aircraft specific data file. Just add this to you aircraft's nasal code so it gets executed once during startup. aircraft.data.add( "/one/property", "/another/property", "/and/another/property" ); Torsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
On Tuesday 20 September 2011 23:25:51 Durk Talsma wrote: > Hi all, > > In referral to my previous posting: Can anybody tell me (or point me to > documentation) how I can specify new property in an aircraft -set.xml > file, and ensure that any changes to this property are saved in an > aircraft specific data file. As an example in the 777-200ER-set.xml, I > have specified /sim/aircraft-operator=NONE, and in the three Model/Livery > xml files (DAL, BA, and KLM, I change this to the corresponding 3-letter > ICAO code, and I want to save this property to use in the next session. > > While I run flightGear, I can see that the property has the right value, > (i.e. KLM, BAW, or DAL, depending which livery file is loaded, but the > problem is that during startup and runway assignment, the value is still > listed as NONE. I've been playing with various versions of archive, and > userarchive, but to no avail. Any hint would be appreciated, as this > seemingly trivial problem is driving me nuts. > > Simple pointers to documentation of the PropertyTree xml do's and don'ts > are also welcome. :-) > > Cheers, > durk > Adding archive="y" to the property tag?: myprop -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
Hi all, In referral to my previous posting: Can anybody tell me (or point me to documentation) how I can specify new property in an aircraft -set.xml file, and ensure that any changes to this property are saved in an aircraft specific data file. As an example in the 777-200ER-set.xml, I have specified /sim/aircraft-operator=NONE, and in the three Model/Livery xml files (DAL, BA, and KLM, I change this to the corresponding 3-letter ICAO code, and I want to save this property to use in the next session. While I run flightGear, I can see that the property has the right value, (i.e. KLM, BAW, or DAL, depending which livery file is loaded, but the problem is that during startup and runway assignment, the value is still listed as NONE. I've been playing with various versions of archive, and userarchive, but to no avail. Any hint would be appreciated, as this seemingly trivial problem is driving me nuts. Simple pointers to documentation of the PropertyTree xml do's and don'ts are also welcome. :-) Cheers, durk -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Property Tree - Diagram
Hello all, Which part of the property tree holds the value(node) if i enabled the following in the FGRUN Advanced->Network->proxy and is there a tree diagram image file of the property tree floating some where in the internet domain? Thank you all -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property tree heads up
On 18 Nov 2010, at 07:50, Erik Hofman wrote: > I think I would have preferred a condition to enable or disable it but > set it to off by default. Sometimes it's a good idea to trade memory > usage for speed but in this case I can see it turn the other way; using > too much memory for it's own good. Yes, but I think the thread-unsafety of the cache was the deciding factor here. We need to move to a world where properties are thread-safe, and this was an obstacle. James -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property tree heads up
On Wed, 2010-11-17 at 11:29 +0100, Tim Moore wrote: > I committed a change that removes the cache from property tree path > lookups. This cache causes significant thread safety and other > headaches, and my tests show a negligible speedup from the caching. If > you notice a big performance hit and you think it might be related to > this change, let me know and we'll take a look. I think I would have preferred a condition to enable or disable it but set it to off by default. Sometimes it's a good idea to trade memory usage for speed but in this case I can see it turn the other way; using too much memory for it's own good. Erik -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] property tree heads up
I committed a change that removes the cache from property tree path lookups. This cache causes significant thread safety and other headaches, and my tests show a negligible speedup from the caching. If you notice a big performance hit and you think it might be related to this change, let me know and we'll take a look. Tim -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] property tree
I'm a new kid on the block but I want to raise and issue. *The Property Tree Documentation* Its taken a while to kinda figure out and research/mind shift as to where its all as there in conflicting information from /src mini-docs with regard to purpose and my intermittent time of research. Where it has led me is to the wiki and even there its kind of a lash/hash/mish/mash up. I'm a web developer by nature and not a compiler. I'd like to feedback and correct/make/edit wiki documentation and make it THE source of reference so It's easy to find; as another newbie like me is trying to find node etc it would be clear which path to follow to interface with FG internally or externally on sockets telnet etc. Now I've taken an initiative (ducks) and created the namespace of PropertyTree: as follows, but need advice before do it proper. PropertyTree: http://wiki.flightgear.org/index.php/PropertyTree What we want Out of that Tree has differenct objetives, eg internal, external, motion sim, cabin light switch and fader level et all Current wiki pages are. http://wiki.flightgear.org/index.php/Property_Tree_Intro http://wiki.flightgear.org/index.php/Property_Tree http://wiki.flightgear.org/index.php/Property_Tree_Servers ( I edited this hence --props above) from http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21190.html http://wiki.flightgear.org/index.php/Property_Tree_Reorganization http://wiki.flightgear.org/index.php/Recommended_Property_Tree_Enhancements http://wiki.flightgear.org/index.php/Howto:Working_with_the_Property_Tree_API http://wiki.flightgear.org/index.php/Property_browser http://wiki.flightgear.org/index.php/Special:Search?search=property&go=Go http://wiki.flightgear.org/index.php/Special:Search?search=tree&go=Go The only reliable one maybe is http://cvs.flightgear.org/viewvc/source/docs-mini/README.properties?view=markup ==Reference== Need to have the generic always there tree Reference ie "constants of somewhat" eg position, flaps, and a clear definition and the nodes of whats "changeable" and sim stuff.. reference here. Most Basic make users aware of how to browse properties and where the target areas are? I believe this is the way to go, its pretty clear in my mind as a newbie. Just need to consolidate it and make it cool and clear, no matter what level. First Major Desicion === --props= /dev/null http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg09152.html So two years later can on irc [23:59] > --props is a method of setting properties remotely Heard that --props is abandoned (is that for real) can someone confirm? [23:58] > so what is the difference between a --telnet and --props [23:59] > nothing so Can that be nuked from references http://wiki.flightgear.org/index.php/Command_Line_Parameters#IO_Options See what happens.. regards Pete ac001 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel