Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.

2011-09-22 Thread Melchior FRANZ
* 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.

2011-09-21 Thread Durk Talsma

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.

2011-09-21 Thread Melchior FRANZ
* 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.

2011-09-21 Thread Melchior FRANZ
* 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.

2011-09-21 Thread Durk Talsma
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.

2011-09-21 Thread Melchior FRANZ
* 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.

2011-09-21 Thread Torsten Dreyer
> 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.

2011-09-21 Thread Melchior FRANZ
* Torsten Dreyer -- Wednesday 21 September 2011:
> 
>
>  

Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.

2011-09-21 Thread Torsten Dreyer
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.

2011-09-21 Thread Durk Talsma
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.

2011-09-21 Thread 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


Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.

2011-09-20 Thread Torsten Dreyer
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.

2011-09-20 Thread Emilian Huminiuc
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.

2011-09-20 Thread Durk Talsma
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

2011-06-23 Thread xsaint
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

2010-11-18 Thread James Turner

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

2010-11-17 Thread Erik Hofman
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

2010-11-17 Thread Tim Moore
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

2009-09-08 Thread AC001
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