Re: [Flightgear-devel] foo-set.xml - foo-yasim-set.xml

2008-04-20 Thread Melchior FRANZ
* Syd -- Saturday 19 April 2008:
 can you name an example so I can see what you mean ? My vote would 
 be to do something about it , so if mine are like this [...]

I haven't looked closely, but I didn't refer to your aircraft.
You get a good impression if you try this:

  $ ls $FG_ROOT/Aircraft/*/*-yasim-set.xml

90% of them add two entries to the --show-aircraft output
for no good reason. (Nobody will do a Farman-IV-jsbsim-set.xml
within the next century. And if so, then we can still add the
necessary files in time. :-)

m.

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] foo-set.xml - foo-yasim-set.xml

2008-04-20 Thread gerard robin
On sam 19 avril 2008, Melchior FRANZ wrote:
 There are more and more aircraft in CVS with two *-set.xml
 files, where one is basically empty and only referring to
 a second one. This is understandable in cases where actually
 more than one FDM is used or very likely to be used in the
 next time. But it's becoming a problem if this redundant
 stuff is routinely added for no good reason. This makes the
 output of --show-aircraft, the list in fgrun, or the output
 of an --aircraft= shell completion script unusable, while it
 has no real advantage.

 I considered to strip all redundant *-set.xml files out in
 --show-aircraft (everything that contains one of
 yasim/jsbsim/uiuc/base) and to only show that with
 --show-aircraft --verbose. But that wouldn't fix the fgrun
 and shell problem, and not even those subtypes are used
 consistently.

 Or should we just watch the cancer and not do anything?  :-}

 m.




Hello,
I have, at least, one  aircraft which could be involved with your remark,  
Blackbird  and Blackbird-B are the same (Blackbird linked to 
Blackbird-B-set.xml).
It had an history reason.
If not useful, now, i can remove Blackbird-set.xml.

Blackbird-A and Blackbird-B both variant each other, are the basic ones. 

Cheers


-- 
GĂ©rard
http://pagesperso-orange.fr/GRTux/


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] foo-set.xml - foo-yasim-set.xml

2008-04-19 Thread Melchior FRANZ
There are more and more aircraft in CVS with two *-set.xml
files, where one is basically empty and only referring to
a second one. This is understandable in cases where actually
more than one FDM is used or very likely to be used in the
next time. But it's becoming a problem if this redundant
stuff is routinely added for no good reason. This makes the
output of --show-aircraft, the list in fgrun, or the output
of an --aircraft= shell completion script unusable, while it
has no real advantage.

I considered to strip all redundant *-set.xml files out in
--show-aircraft (everything that contains one of
yasim/jsbsim/uiuc/base) and to only show that with
--show-aircraft --verbose. But that wouldn't fix the fgrun
and shell problem, and not even those subtypes are used
consistently.

Or should we just watch the cancer and not do anything?  :-}

m.


btw: also some livery *-set.xml files like the three 787{ANA,CO,FC}
 should IMHO be merged, and livery handling be supported
 at runtime, like it's done in the dhc6.

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] foo-set.xml - foo-yasim-set.xml

2008-04-19 Thread Syd
Melchior FRANZ wrote:
 There are more and more aircraft in CVS with two *-set.xml
 files, where one is basically empty and only referring to
 a second one. This is understandable in cases where actually
 more than one FDM is used or very likely to be used in the
 next time. But it's becoming a problem if this redundant
 stuff is routinely added for no good reason. This makes the
 output of --show-aircraft, the list in fgrun, or the output
 of an --aircraft= shell completion script unusable, while it
 has no real advantage.

 I considered to strip all redundant *-set.xml files out in
 --show-aircraft (everything that contains one of
 yasim/jsbsim/uiuc/base) and to only show that with
 --show-aircraft --verbose. But that wouldn't fix the fgrun
 and shell problem, and not even those subtypes are used
 consistently.

 Or should we just watch the cancer and not do anything?  :-}

 m.


 btw: also some livery *-set.xml files like the three 787{ANA,CO,FC}
  should IMHO be merged, and livery handling be supported
  at runtime, like it's done in the dhc6.

 -
 This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
 Don't miss this year's exciting event. There's still time to save $100. 
 Use priority code J8TL2D2. 
 http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel

   
Hi m ,
  can you name an example so I can see what you mean ? My vote would 
be to do something about it , so if mine are like this , I'll fix them 
... and concerning the 787 , it nearly locks up FGrun here ...i get a 
lot of disc thrashing for several minutes ... but fortunately I only use 
fgrun as a model  viewer...
Syd

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] foo-set.xml - foo-yasim-set.xml

2008-04-19 Thread Vivian Meazza
Melchior Franz wrote

 Sent: 19 April 2008 07:57
 To: flightgear-devel@lists.sourceforge.net
 Subject: [Flightgear-devel] foo-set.xml - foo-yasim-set.xml
 
 
 There are more and more aircraft in CVS with two *-set.xml 
 files, where one is basically empty and only referring to a 
 second one. This is understandable in cases where actually 
 more than one FDM is used or very likely to be used in the 
 next time. But it's becoming a problem if this redundant 
 stuff is routinely added for no good reason. This makes the 
 output of --show-aircraft, the list in fgrun, or the output 
 of an --aircraft= shell completion script unusable, while it 
 has no real advantage.
 
 I considered to strip all redundant *-set.xml files out in 
 --show-aircraft (everything that contains one of
 yasim/jsbsim/uiuc/base) and to only show that with 
 --show-aircraft --verbose. But that wouldn't fix the fgrun 
 and shell problem, and not even those subtypes are used consistently.
 
 Or should we just watch the cancer and not do anything?  :-}
 
 m.
 
 
 btw: also some livery *-set.xml files like the three 787{ANA,CO,FC}
  should IMHO be merged, and livery handling be supported
  at runtime, like it's done in the dhc6.
 

I don't think we want multiple entries in fgrun etc. which refer to the same
aircraft model. Each entry shown should select a unique aircraft model.
There are surprisingly few entries which actually adhere to this principle.
I suspect that this might be a case where a useful file structure has been
blindly copied and used where it is really not required. 

Now that liveries can be selected at runtime, and can be transferred over
MP, different liveries should not count as unique aircraft.

If we agree the principle, we then need to work out how to crawl out of the
mess. It isn't going to be all that easy or trivial.

Vivian




-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel