Re: [Flightgear-devel] Use of included xml files from Instruments-3d/* from an aircraft located outside of $FG_ROOT

2011-02-14 Thread Hal V. Engel 
On Sunday, February 13, 2011 11:30:05 PM ThorstenB wrote:
> On 14.02.2011 07:58, Hal V. Engel wrote:
> > When working on this from an aircraft that is not located in $FG_ROOT
> > (IE. my clone of fg-data using fg-aircraft= > aircraft>) I was getting file not found errors. At first I though that
> > perhaps I had a typo or something similar in my code but after looking
> > things over very carefully I couldn't find the problem. So as a test I
> > modified the aircraft-set.xml for the same aircraft in $FG_ROOT and
> > tested with it and it didn't have the problem. I did some more testing
> > and found if I run the aircraft from my development copy of fgdata it
> > works but only if the xml file I am including in the aircraft-set.xml
> > file is located in the same tree as the aircraft. So it does not find
> > it in the $FG_ROOT directories like it should based on how the
> > fg-aircraft stuff has been explained. Is this a bug or I am not
> > understanding how this should work?
> 
> It should work - and does for me. But remember the "fg-aircraft" option
> does not support multiple fgdata clones. Neither should you give it the
> path to a specific aircraft directory. You need to provide a directory
> path, which contains one or multiple aircraft sub-directories.
> It should look like this:
>  "--fg-aircraft=/home/foo/bar/MyAircraftRepository"
> and "/home/foo/bar/MyAircraftRepository" should contain directories like
>  /home/foo/bar/MyAircraftRepository/747-400
>  /home/foo/bar/MyAircraftRepository/P51-D
>  /home/foo/bar/MyAircraftRepository/AH-1
>  ...
> 
> Otherwise, post some more details on what your command-line and the
> directory structure of the separate aircraft repo looks like.
> 
> And yes, as discussed on the list before, the fg-aircraft option
> requires better checks and error messages, since more people have had
> trouble with providing the correct directory structure (especially since
> incorrect structures seem to work at first - but then really don't).
> 
> cheers,
> Thorsten


I keep a current copy of fgdata at $FG_ROOT which is currently located at 
/usr/share/games/FlightGear.  I have my cloned copy of fgdata located in
~/Sources/fgdata.  My fg-aircraft setting looks like this:

fg-aircraft=<$HOME>/Sources/fgdata/Aircraft/p51d

Since I want FG to pick up the p51d specific files from the fg-aircraft 
directory and everything else from $FG_ROOT since $FG-ROOT is synced to the 
version of FG I have installed.   But I guess that I was using this 
incorrectly and I just tried it using 

fg-aircraft= <$HOME>/Sources/fgdata/Aircraft/ 

and things worked but now it is picking up the stuff in Instruments-3d from the 
fg-aircraft tree rather than $FG_ROOT.  This will actually make thing a little 
easier for managing the sources.

Sorry for the noise.

Hal 

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] c172p scissors interpolations and main rotation interpolations

2011-02-14 Thread Torsten Dreyer 
> On 02/14/2011 11:58 AM, Torsten Dreyer wrote:
> >> On 02/12/2011 12:59 PM, Torsten Dreyer wrote:
>  By the way.  The filtering that will remain in the c172p
>  action-sim.nas for the nav radio could be moved to navradio.cxx.  Here
>  again, the needle damping and the needle behavior when tuned to an
>  out-of-range frequency or when the gs is out of range is device
>  dependent.  The filtered values are used by
>  Aircraft/Instruments-3d/vor/vor.xml and vor2.xml.  I was afraid that
>  modifying navradio.cxx to achieve realistic needle behavior for this
>  vor model might break other vor/gs head or hsi models.
> >>>
> >>> We can now easily use the autopilot filters for that, just add a file
> >>> with the content
> >>>
> >>> 
> >>> 
> >>>   CDI0 lowpass
> >>>   false
> >>>   exponential
> >>>   2.0
> >>>  
> >>> instrumentation/nav[0]/heading-needle-deflection-norm
> >>> instrumentation/nav[0]/filtered-cdiNAV0-deflection
> >>> 
> >>> 
> >>> 
> >>>
> >>> And add
> >>> 
> >>> A very descriptive name for this file like
> >>> Instrument-Filter  Aircraft/c172p/path/to/that/file
> >>> 
> >>>
> >>> to c172p-set.xml under /sim/systems
> >>>
> >>> No need for coding here, too.
> >>>
> >>> Greetings, Torsten
> >>
> >> I had not tried the kap140 in checking out the changes I submitted today
> >> for the c172p.  While implementing similar changes to the pa24-250, I
> >> noticed that neither the Century IIB not the Century III autopilots work
> >> with the above filter method.  So I flew the c172p again and sure
> >> enough, the kap140 is also broken by the above filter method.
> >> Apparently having two autopilots in the same AC "ist verboten".
> >> Torsten, have you tried two autopilots on an AC in the past?
> >
> > No, it's not "verboten" at all. I use four(!) autopilot files in the
> > SenecaII (I prefer to call them property-rules because they are much more
> > than just autopilot components).
> >
> > One pitfall is that in preferences.xml there is the generic-autopilot-
> > helper.xml included at /sim/systems/autopilot[1]. If you add a second
> > autopilot (property-rule), this one gets ignored/overwritten. If you rely
> > on the properties handled there (and I assume the 172p does), you need to
> > re-add it manually. Add
> >   
> >  autopilot helpers
> >  Aircraft/Generic/generic-autopilot-helper.xml
> > 
> > together with your new rule and it should work.
> >
> > Torsten
> 
> Thanks Torsten,
> 
> I should have looked at the SenecaII set and base files.  The answer to
> my question ... have you tried ... was there.  I still would not have
> thought of the generic helper.
> 
> Thanks again,
> Dave P.
Credit goes to James Turner, who figured that out after we had moved the 
autopilot helpers to the xml file. Back than, we decided to call this a 
"feature" and a way to encourage people to move away from the generic "helper" 
classes.
Didn't turn out so well ;-)

Torsten

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] c172p scissors interpolations and main rotation interpolations

2011-02-14 Thread dave perry 
On 02/14/2011 11:58 AM, Torsten Dreyer wrote:
>> On 02/12/2011 12:59 PM, Torsten Dreyer wrote:
 By the way.  The filtering that will remain in the c172p action-sim.nas
 for the nav radio could be moved to navradio.cxx.  Here again, the
 needle damping and the needle behavior when tuned to an out-of-range
 frequency or when the gs is out of range is device dependent.  The
 filtered values are used by Aircraft/Instruments-3d/vor/vor.xml and
 vor2.xml.  I was afraid that modifying navradio.cxx to achieve realistic
 needle behavior for this vor model might break other vor/gs head or hsi
 models.
>>> We can now easily use the autopilot filters for that, just add a file
>>> with the content
>>>
>>> 
>>> 
>>>   CDI0 lowpass
>>>   false
>>>   exponential
>>>   2.0
>>>   instrumentation/nav[0]/heading-needle-deflection-norm
>>>   instrumentation/nav[0]/filtered-cdiNAV0-deflection
>>> 
>>> 
>>> 
>>>
>>> And add
>>> 
>>> A very descriptive name for this file like
>>> Instrument-Filter  Aircraft/c172p/path/to/that/file
>>> 
>>>
>>> to c172p-set.xml under /sim/systems
>>>
>>> No need for coding here, too.
>>>
>>> Greetings, Torsten
>> I had not tried the kap140 in checking out the changes I submitted today
>> for the c172p.  While implementing similar changes to the pa24-250, I
>> noticed that neither the Century IIB not the Century III autopilots work
>> with the above filter method.  So I flew the c172p again and sure
>> enough, the kap140 is also broken by the above filter method.
>> Apparently having two autopilots in the same AC "ist verboten".
>> Torsten, have you tried two autopilots on an AC in the past?
> No, it's not "verboten" at all. I use four(!) autopilot files in the SenecaII
> (I prefer to call them property-rules because they are much more than just
> autopilot components).
>
> One pitfall is that in preferences.xml there is the generic-autopilot-
> helper.xml included at /sim/systems/autopilot[1]. If you add a second
> autopilot (property-rule), this one gets ignored/overwritten. If you rely on
> the properties handled there (and I assume the 172p does), you need to re-add
> it manually. Add
>   
>  autopilot helpers
>  Aircraft/Generic/generic-autopilot-helper.xml
> 
> together with your new rule and it should work.
>
> Torsten
>
Thanks Torsten,

I should have looked at the SenecaII set and base files.  The answer to 
my question ... have you tried ... was there.  I still would not have 
thought of the generic helper.

Thanks again,
Dave P.

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] c172p scissors interpolations and main rotation interpolations

2011-02-14 Thread Torsten Dreyer 
> On 02/12/2011 12:59 PM, Torsten Dreyer wrote:
> >> By the way.  The filtering that will remain in the c172p action-sim.nas
> >> for the nav radio could be moved to navradio.cxx.  Here again, the
> >> needle damping and the needle behavior when tuned to an out-of-range
> >> frequency or when the gs is out of range is device dependent.  The
> >> filtered values are used by Aircraft/Instruments-3d/vor/vor.xml and
> >> vor2.xml.  I was afraid that modifying navradio.cxx to achieve realistic
> >> needle behavior for this vor model might break other vor/gs head or hsi
> >> models.
> >
> > We can now easily use the autopilot filters for that, just add a file
> > with the content
> >
> > 
> >
> >  CDI0 lowpass
> >  false
> >  exponential
> >  2.0
> >  instrumentation/nav[0]/heading-needle-deflection-norm
> >  instrumentation/nav[0]/filtered-cdiNAV0-deflection
> >
> >
> > 
> >
> > And add
> > 
> >A very descriptive name for this file like
> > Instrument-Filter Aircraft/c172p/path/to/that/file
> > 
> >
> > to c172p-set.xml under /sim/systems
> >
> > No need for coding here, too.
> >
> > Greetings, Torsten
> 
> I had not tried the kap140 in checking out the changes I submitted today
> for the c172p.  While implementing similar changes to the pa24-250, I
> noticed that neither the Century IIB not the Century III autopilots work
> with the above filter method.  So I flew the c172p again and sure
> enough, the kap140 is also broken by the above filter method.
> Apparently having two autopilots in the same AC "ist verboten".
> Torsten, have you tried two autopilots on an AC in the past?
No, it's not "verboten" at all. I use four(!) autopilot files in the SenecaII 
(I prefer to call them property-rules because they are much more than just 
autopilot components).

One pitfall is that in preferences.xml there is the generic-autopilot-
helper.xml included at /sim/systems/autopilot[1]. If you add a second 
autopilot (property-rule), this one gets ignored/overwritten. If you rely on 
the properties handled there (and I assume the 172p does), you need to re-add 
it manually. Add
 
autopilot helpers
Aircraft/Generic/generic-autopilot-helper.xml
   
together with your new rule and it should work.

Torsten

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Carrier Altitude

2011-02-14 Thread henri orange 
Hi jano,

I just notice a big issue with a cruise toward and under the Golden Bridge.
The terrain_hight is disturbed ( a sudden jump of the ship ),  since
geodinfo, when the Ship is under the Bridge, refer to the terrain_hight of
the  Bridge surface.
Was it  solved  with your patch ?


2011/2/14 henri orange 

> Hi, Jano,
>
> I guess i understand my issue, with your patch
> I am working with 3D models whose the XY axis are under the deck. The wake
> 3D object had been replaced by particles effect  ( osg model ).
> The consequence is , the lon and lat coordinate given to geodinfo are under
> the deck.
>
>
> 2011/2/14 jean 
>
> Le 13/02/2011 23:32, henri orange a écrit :
>> > Hi, Peter
>> >
>> > I have done from an old code by Gérard a process which answer to the
>> > request.
>> > It adjust the altitude of the Carrier, when cruising, according to the
>> > visual surface of the water.
>> > But mistake, it does answer to any condition, including the Tsumani
>> > effect when two tiles are not the same hight.
>> > The presentation of the project is there:
>> > http://www.flightgear.org/forums/viewtopic.php?f=4&t=11043
>> > 
>> > It should, could, must, be improved.
>> >
>> > Hi, Jean
>> >
>> > I have tried to use your patch, i could not get it to work.
>> > Seems to get the same issue than with an old version by Gérard.
>> > geodinfo  is giving the terrain_hight, which is the carrier Deck
>> > surface not the water surface.
>> >
>> hi henri,
>>
>> my patch is only for the mp carriers when you command it, not for the ai
>> carriers, and the position of the point from wich geodinfo is used works
>> fine (here) with the Nimitz, Vinson, Eisenhower and clemenceau.
>> but you need to have a non solid wake, and no deck below the reference
>> point you consider to use geodinfo.
>>
>> jano
>>
>>
>>
>>
>>
>> --
>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
>> Pinpoint memory and threading errors before they happen.
>> Find and fix more than 250 security defects in the development cycle.
>> Locate bottlenecks in serial and parallel code that limit performance.
>> http://p.sf.net/sfu/intel-dev2devfeb
>> ___
>> Flightgear-devel mailing list
>> Flightgear-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>>
>
>
>
> --
> Best regards,
>
> Henri, aka Alva
> Official grtux hangar maintainer
>
>


-- 
Best regards,

Henri, aka Alva
Official grtux hangar maintainer
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Carrier Altitude

2011-02-14 Thread henri orange 
Hi, Jano,

I guess i understand my issue, with your patch
I am working with 3D models whose the XY axis are under the deck. The wake
3D object had been replaced by particles effect  ( osg model ).
The consequence is , the lon and lat coordinate given to geodinfo are under
the deck.


2011/2/14 jean 

> Le 13/02/2011 23:32, henri orange a écrit :
> > Hi, Peter
> >
> > I have done from an old code by Gérard a process which answer to the
> > request.
> > It adjust the altitude of the Carrier, when cruising, according to the
> > visual surface of the water.
> > But mistake, it does answer to any condition, including the Tsumani
> > effect when two tiles are not the same hight.
> > The presentation of the project is there:
> > http://www.flightgear.org/forums/viewtopic.php?f=4&t=11043
> > 
> > It should, could, must, be improved.
> >
> > Hi, Jean
> >
> > I have tried to use your patch, i could not get it to work.
> > Seems to get the same issue than with an old version by Gérard.
> > geodinfo  is giving the terrain_hight, which is the carrier Deck
> > surface not the water surface.
> >
> hi henri,
>
> my patch is only for the mp carriers when you command it, not for the ai
> carriers, and the position of the point from wich geodinfo is used works
> fine (here) with the Nimitz, Vinson, Eisenhower and clemenceau.
> but you need to have a non solid wake, and no deck below the reference
> point you consider to use geodinfo.
>
> jano
>
>
>
>
>
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>



-- 
Best regards,

Henri, aka Alva
Official grtux hangar maintainer
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel