Re: [Flightgear-devel] New Architecture for Flightgear

[Robin]

Martin Spott schreef:
> Well, we've been driving two 'external' displays on last years LinuxTag
> exhibition using the 'generic' protocol. We were surprised to encounter
> a significant performance hit on the master machine serving two clients
> at 20 Hz. Throttling the thing down to 10 Hz made the whole setup
> flyable again.
> Yet this might look different if such master does nothing but FDM
> output via network,
>
>   Martin.
>   
Keep in mind that the Generic protocol is one of the most inefficient 
for real-time data communication, as it communicates via plain text. If 
you want something that goes over 100Hz, you need to think of a binary 
system. For an FDM connecting to a visual system it's basically nothing 
more than 18 floating point values (x,y,z, rotation xyz and first and 
second order derivatives for smoothing) resulting in a 72-byte data 
packet, which is doable.

To put it into perspective, the same 18 values would take up at least 
200 bytes (characters), not counting newlines and frame separators, as 
each floating point would need at least 10 characters to be represented 
at least a bit accurately, and still you have to cope with international 
issues (comma vs. decimal point) when you're using the generic protocol. 
Plus a terrible loss in resolution as the max. resolution for a plain 
text channel can be at most to the 10th decimal place (at least, in 
standard format) where a double floating point can carry much more 
accurate data.

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Linux in real-world aviation (was: FG and VATSIM)

[Robin]

Curtis Olson wrote:
> 3. I'll just toss in this unrelated item ... a week ago I got to fly 
> on a NWA A330.  This aircraft had individual movie/music/game/map 
> displays for each seat.  I managed to hang/lock mine up ... apparently 
> because the map wasn't working on this flight for some reason.  So I 
> asked the flight attendent to reset the display and when she did, it 
> booted Linux of all things!  I thought that was interesting.
>
> Regards,
>
> Curt.
> -- 
> Curtis Olson - University of Minnesota - FlightGear Project
> http://baron.flightgear.org/~curt/ 
>    
> http://www.humanfirst.umn.edu/  http://www.flightgear.org
> Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
Linux isn't FAA certified so it's not used for mission-critical systems 
but in-flight entertainment systems would be very useful on Linux. You 
managed to figure out what distro the Airbus was running? Some custom one?

I do know that there is enough FAA certified hardware on the market 
capable of running RT-Linux, and I expect to see some of that hardware 
bleeding onto the instrument market. The A380 already does PC-based 
systems in its flight deck, although probably not in its entirety. 
Programming instrumentation in OpenGL is the way to go, and the avionics 
manufacturers picked that up, look at the ARINC661 standard for example.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Linux in real-world aviation

[Robin]

Ralf Gerlich wrote:
> I don't know whether this should be termed a good thing. Or why should
> Linux-advocates be proud of their operating system being seen rebooting
> on two independent instances? ;-)
>
> Cheers,
> Ralf
>   
They would be more concerned about what was happening BEFORE the reboot. 
The fact that the system reboots only proves the fool-proofness of it, 
as the IFE system comes happily back up again and continues what it was 
doing before :)

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] tunnel for glide slope visualization

[Robin]

Bill Galbraith wrote:
> Okay, that looks really good.
>
> Now, let's make it more challenging. Let's see circles to get me back to the
> squares in a reasonable amount of time ;-}
>
> Bill
>   
Does the line geometry run through OSG? Might be a very good starting 
point of converting the HUD to an OSG-driven one.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] More 3D cloud changes

[gerard robin]

On lundi 15 décembre 2008, Yon Uriarte wrote:
> Hi,
>
> On Mon, Dec 15, 2008 at 10:20 AM, Tim Moore  wrote:
> > Yon Uriarte wrote:
SNIP
>
>   Yeah, at least not here (3870, 10x overkill for FG).
>   I maximize the window from default (800x600?) to aprox
> 1600x1200 and the frame rate stays constant. This rules out texture-, fill-
> or blend-rate
> bottlenecks. I seriously doubt we are vertex bottlenecked (to state the
> obvious).

I don't know if that may help but i am permanently using 1920x1440  , i don't 
notice any fps problem osg 3Dclouds versus osg 3Dclouds.
Only the Aircraft model may give a significant decrease of FPS.

The diff is only only FG plib 3Dclouds versus osg 3Dclouds, that was talked  
some month ago ,we must forget it,  it is not the purpose of that topic.



>
>
> greetings,
>  yon

Cheers

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FlightGear-1.99.5-RC2

[gerard robin]

On mercredi 17 décembre 2008, Frederic Bouvier wrote:
> - "gerard robin" a écrit :
> > On mardi 16 décembre 2008, Durk Talsma wrote:
> > > Hi Fred,
> > >
> > > On Saturday 13 December 2008 18:50:51 Frederic Bouvier wrote:
> > > > I replied that the target is next Friday. After that I may have
> > > > difficulties to build a binary from where I will be.
> > > >
> > > > -Fred
> > >
> > > How would your availability be after Friday. As it turns out, I have
> >
> > a
> >
> > > Christmas dinner this Friday, so I won't be able assemble the final
> >
> > release
> >
> > > by then. Saturday will be fine for me, so I hope to roll up the
> >
> > release
> >
> > > then.
> > >
> > > Cheers,
> > > Durk
> >
> > Hello, Durk
> >
> > How do you schedule  the  period test  with OSG 2.8 before rolling up
> > the
> > release ?
> > OR do you avoid any test with it ?
>
> A lot of people are already using OSG/SVN. So tests are going on under the
> hood.
>
> -Fred

Sorry for that  question which seems to annoy everybody.
I agree, the question was not realistic and not constructive, it was stupid.
I am glad to know that there is a LOT of persons testing it.
  :)  :)

Merry Christmas  :) 
See you next year.

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FlightGear-1.99.5-RC2

[gerard robin]

On mardi 16 décembre 2008, Durk Talsma wrote:
> Hi Fred,
>
> On Saturday 13 December 2008 18:50:51 Frederic Bouvier wrote:
> > I replied that the target is next Friday. After that I may have
> > difficulties to build a binary from where I will be.
> >
> > -Fred
>
> How would your availability be after Friday. As it turns out, I have a
> Christmas dinner this Friday, so I won't be able assemble the final release
> by then. Saturday will be fine for me, so I hope to roll up the release
> then.
>
> Cheers,
> Durk
>
Hello, Durk 

How do you schedule  the  period test  with OSG 2.8 before rolling up the 
release ?
OR do you avoid any test with it ?

Cheers


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] units analysis ... factor label method

[gerard robin]

On mercredi 17 décembre 2008, John Denker wrote:
> On 12/17/2008 12:33 AM, James Turner wrote:
> > On 17 Dec 2008, at 01:03, Melchior Franz wrote:
> >> + var KT2MPS = 0.51; # knots to m/s
> >> + var MPS2KT = 1 / KT2MPS;
> >> +
> >>  var LB2KG = 0.45359237;# pounds to kilogram
> >>  var KG2LB = 1 / LB2KG;
> >
> > Personally I think all these constants would be easier to read if they
> > were written the same way as the Simgear ones, i.e MPS_TO_KT, NM_TO_M
> > and so on. I understand the logic behind using '2' but it makes the
> > identifiers rather dense.
>
> The tradition in the scientific community in recent decades
> has been to do neither of the above.  The best current
> practice is called "unit analysis" or the "factor label
> method".
>
> The essential idea is to consider _units_ as first-class
> algebraically-meaningful objects.
>
> Here are some examples:  Given any self-consistent set of
> base units (usually SI but not necessarily) we can write:
> inch = .0245 * meter;
> foot = 12 * inch;
> mile = 5280 * foot;
> furlong = (1/8) * mile;
> minute = 60 * second;
> hour = 60 * minute;
> day = 24 * hour;
> fortnight = 14 * day;
>
> Then, given that set of units, if you want to express (say) a
> velocity that was measured in units of furlongs per fortnight,
> you just say so:
> v = 1.2345 * furlong / fortnight; [1]
>
> Equation [1] converts _from_ arbitrary units _to_ base units.
> If you want to convert the other way around, you use the
> reciprocals of the units.
>
> The advantages in terms of concision, precision, and clarity
> are rather dramatic.
>
> In this system, you don't need a conversion factor such as
> furlong_per_fortnight_2_meter_per_second ... the question
> just never comes up, because there are easier ways to do
> what needs to be done.

 BTW: there is a nice stand alone tool
that i am using.

http://convertall.bellz.org/

You may notice 
the units.dat file which is using  that "scientific" notation

Cheers


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FlightGear-1.99.5-RC2

[gerard robin]

On mercredi 17 décembre 2008, Frederic Bouvier wrote:
> - "gerard robin" a écrit :
> > On mercredi 17 décembre 2008, Frederic Bouvier wrote:
> > > - "gerard robin" a écrit :
> > > > On mardi 16 décembre 2008, Durk Talsma wrote:
> > > > > Hi Fred,
> > > > >
> > > > > On Saturday 13 December 2008 18:50:51 Frederic Bouvier wrote:
> > > > > > I replied that the target is next Friday. After that I may
> >
> > have
> >
> > > > > > difficulties to build a binary from where I will be.
> > > > > >
> > > > > > -Fred
> > > > >
> > > > > How would your availability be after Friday. As it turns out, I
> >
> > have
> >
> > > > a
> > > >
> > > > > Christmas dinner this Friday, so I won't be able assemble the
> >
> > final
> >
> > > > release
> > > >
> > > > > by then. Saturday will be fine for me, so I hope to roll up the
> > > >
> > > > release
> > > >
> > > > > then.
> > > > >
> > > > > Cheers,
> > > > > Durk
> > > >
> > > > Hello, Durk
> > > >
> > > > How do you schedule  the  period test  with OSG 2.8 before rolling
> >
> > up
> >
> > > > the
> > > > release ?
> > > > OR do you avoid any test with it ?
> > >
> > > A lot of people are already using OSG/SVN. So tests are going on
> >
> > under the
> >
> > > hood.
> > >
> > > -Fred
> >
> > Sorry for that  question which seems to annoy everybody.
> > I agree, the question was not realistic and not constructive, it was
> > stupid.
> > I am glad to know that there is a LOT of persons testing it.
> >
> >   :)  :)
> >
> > Merry Christmas  :)
> > See you next year.
>
> Is it me or are you implying you are the only one to care, and there are
> nobody at the moment committing patches and building binaries for the
> community ?
>
> Anyway merry christmas.
>
> -Fred
Fred,
I only apologized regarding my question (a stupid question which got, from 
you, the suitable answer).
I know, that,  the effort i did,  to get the right computer/configuration in 
order to build FG with OSG 2.75, and the feedback that i gave about the new 
3D Clouds with Metar, was not useful.
In anycase less useful than your contributions, like you suggested. 
Anyhow, i am leaving out, from any computer until next year.

Greetings to everybody


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FG ocean water shader / water region issue.

[gerard robin]

On mercredi 07 janvier 2009, Vladimir Karmisin wrote:
> Hello !
> In past couple of weeks I wrote GLSL-based shader for fluid surfaces and
> now trying to deploy it into FlightGear.
> As far as I know - there's no diference between solid and liquid surfaces
> from FG/SG point of view. In other words
> - rivers, lakes, ocean are a part of TerraGear scenery (except OceanTiles
> for non existent BTG-s of course).
>
> To make shader work propertly - probally I have to embedd a fluids into
> separate graph of scene (or into a subgraph
> of terrain), and assign a StateSet, containing shader and all of it data to
> it.
>
> If anyone have any idea or suggestion - how water can be separated from
> terrain, please drop me a note, right
> now all idea I have is only to determine quality of a BTG object by
> it's material name.
Hello
I am not sure that could answer your question, however i do use the following 
nasal script to know if there is water or solid  under.

terrain_under = func {
var lat = getprop("/position/latitude-deg");
var lon = getprop("/position/longitude-deg");
var info = geodinfo(lat, lon);
if (info != nil) {
if (info[1] != nil)
setprop("/environment/terrain",info[1].solid);
   #print("and it is ", info[1].solid ? "solid ground" : "covered by 
water");
   #debug.dump(geodinfo(lat, lon));
}else {
setprop("/environment/terrain",1);
}
settimer (terrain_under, 0.1);
}


 so :)

Happy new year

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Openal with OpenSUSE ?????

[gerard robin]

Hello,

Arrgh, i never had any problem with OpenAl  before , coming back to the 
computer i am trying  to build FG CVS , i get the following error with 
Simgear during configure

checking for library containing XShmCreateImage... -lXext
checking for library containing XGetExtensionVersion... -lXi
checking for library containing IceOpenConnection... -lICE
checking for library containing SmcOpenConnection... -lSM
checking for library containing XtMalloc... -lXt
checking for library containing XmuLookupStandardColormap... -lXmu
checking for library containing glNewList... -lGL
checking for library containing gluLookAt... -lGLU
checking for library containing glutGetModifiers... -lglut
checking for library containing alGenBuffers... no
checking for library containing alutInit... -lalut

You *must* have the openal library installed on your system to build
SimGear!

Please see README.OpenAL for more details.

configure aborted.



In that distrib/installation (OpenSUSE 11.1 64bit)  
 openal , openal-32bit , openal-devel, freealut, freealut-devel 
are installed correctly.

Is there anything new within FG that i have missed ?

I don't know if there is the same error with FG 1.9
(i did not tried to build it waiting for OSG 2.8) 

Cheers

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Openal with OpenSUSE ?????

[gerard robin]

On vendredi 09 janvier 2009, gerard robin wrote:
> Hello,
>
> Arrgh, i never had any problem with OpenAl  before , coming back to the
> computer i am trying  to build FG CVS , i get the following error with
> Simgear during configure
>
> checking for library containing XShmCreateImage... -lXext
> checking for library containing XGetExtensionVersion... -lXi
> checking for library containing IceOpenConnection... -lICE
> checking for library containing SmcOpenConnection... -lSM
> checking for library containing XtMalloc... -lXt
> checking for library containing XmuLookupStandardColormap... -lXmu
> checking for library containing glNewList... -lGL
> checking for library containing gluLookAt... -lGLU
> checking for library containing glutGetModifiers... -lglut
> checking for library containing alGenBuffers... no
> checking for library containing alutInit... -lalut
>
> You *must* have the openal library installed on your system to build
> SimGear!
>
> Please see README.OpenAL for more details.
>
> configure aborted.
>
>
>
> In that distrib/installation (OpenSUSE 11.1 64bit)
>  openal , openal-32bit , openal-devel, freealut, freealut-devel
> are installed correctly.
>
> Is there anything new within FG that i have missed ?
>
> I don't know if there is the same error with FG 1.9
> (i did not tried to build it waiting for OSG 2.8)
>
> Cheers

In addition to it 
alut.h which is there /usr/include/AL  
contains 

/* Create Buffer objects */
AL_API void AL_APIENTRY alGenBuffers( ALsizei n, ALuint* buffers );

/* Delete Buffer objects */
AL_API void AL_APIENTRY alDeleteBuffers( ALsizei n, const ALuint* buffers );

/* Verify a handle is a valid Buffer */
AL_API ALboolean AL_APIENTRY alIsBuffer( ALuint bid );

So, where is the error ?
-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Openal with OpenSUSE ?????

[gerard robin]

On vendredi 09 janvier 2009, Craig Benbow wrote:
> gerard robin wrote:
> > On vendredi 09 janvier 2009, gerard robin wrote:
> >> Hello,
> >>
> >> Arrgh, i never had any problem with OpenAl  before , coming back to the
> >> computer i am trying  to build FG CVS , i get the following error with
> >> Simgear during configure
> >>
> >> checking for library containing XShmCreateImage... -lXext
> >> checking for library containing XGetExtensionVersion... -lXi
> >> checking for library containing IceOpenConnection... -lICE
> >> checking for library containing SmcOpenConnection... -lSM
> >> checking for library containing XtMalloc... -lXt
> >> checking for library containing XmuLookupStandardColormap... -lXmu
> >> checking for library containing glNewList... -lGL
> >> checking for library containing gluLookAt... -lGLU
> >> checking for library containing glutGetModifiers... -lglut
> >> checking for library containing alGenBuffers... no
> >> checking for library containing alutInit... -lalut
> >>
> >> You *must* have the openal library installed on your system to build
> >> SimGear!
> >>
> >> Please see README.OpenAL for more details.
> >>
> >> configure aborted.
> >>
> >>
> >>
> >> In that distrib/installation (OpenSUSE 11.1 64bit)
> >>  openal , openal-32bit , openal-devel, freealut, freealut-devel
> >> are installed correctly.
> >>
> >> Is there anything new within FG that i have missed ?
> >>
> >> I don't know if there is the same error with FG 1.9
> >> (i did not tried to build it waiting for OSG 2.8)
> >>
> >> Cheers
> >
> > In addition to it
> > alut.h which is there /usr/include/AL
> > contains
> >
> > /* Create Buffer objects */
> > AL_API void AL_APIENTRY alGenBuffers( ALsizei n, ALuint* buffers );
> >
> > /* Delete Buffer objects */
> > AL_API void AL_APIENTRY alDeleteBuffers( ALsizei n, const ALuint* buffers
> > );
> >
> > /* Verify a handle is a valid Buffer */
> > AL_API ALboolean AL_APIENTRY alIsBuffer( ALuint bid );
> >
> > So, where is the error ?
>
> On the system here OpenSUSE 11.1 and previously 11.0 you will find there
> is two lots of AL headers available after the installation of OpenAL.  I
> think that was the cause of the problem I had here but I can't remember
> for sure.  I'm pretty certain I installed the stuff off the Creative
> Labs site and am not using the SUSE packages but don't shoot me if I got
> that wrong:)
>
> Craig
>

Right
the wrong OpenAl was installed.
The right (working with FG) one is called openal-soft and openal-soft-devel, 
fortunately the openal-32bits can remain (no RPM conflict).
Simgear can be built.

Thanks to everybody for the answer 


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Segfault in FGAirport::ge tIteratorForRunwayIdent()

[gerard robin]

On vendredi 09 janvier 2009, James Turner wrote:
> On 9 Jan 2009, at 11:17, James Turner wrote:
> > If anyone else is seeing this (or isn't, with a clean, up-to-date
> > tree), that'd be very helpful information, since I'm not.
>
> Never mind, I can reproduce this locally on my (Vmware) ubuntu, so
> it's something Linux-y, not a build issue.
>
> Will commit a fix once I track down what my going on. Very werid.
>
> James
>
>
get same kind of crash here with gdb:

[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x0088c7c9 in FGAirport::getIteratorForRunwayIdent(std::string const&) 
const ()
Current language:  auto; currently c++




-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Segfault in FGAirport::ge tIteratorForRunwayIdent()

[gerard robin]

On vendredi 09 janvier 2009, James Turner wrote:
> On 9 Jan 2009, at 13:18, gerard robin wrote:
> > get same kind of crash here with gdb:
> >
> > [Thread debugging using libthread_db enabled]
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x0088c7c9 in
> > FGAirport::getIteratorForRunwayIdent(std::string const&)
> > const ()
> > Current language:  auto; currently c++
>
> Fix is in now, completely obvious thing, what's weird is that I've
> been running with that change for over a week on Mac, and done several
> clean rebuilds in that time.
>
> James
>
>
solved

thanks 



-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Very bad surprise with last FG cvs

[gerard robin]

Hello,

What happen now with the Cockpit view
Getting now the cockpit cutted 

Here two snapshots:

 the first one is done with an older fg CVS version ( 17-12-2008) still 
running on my system
http://pagesperso-orange.fr/GRTux/Before-was-right.jpg

the second one done with the last CVS version (today) running on an other 
system
http://pagesperso-orange.fr/GRTux/Now-is-wrong.jpg

Same aircraft , same pilot position


In addition to it , i have never seen,  clouds so well displayed in reality, 
look like soldiers in parade :)   
this made laughing, guy whom i tried to demonstrate FG.   :(  :(


cheers
-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Very bad surprise with last FG cvs

[gerard robin]

On vendredi 09 janvier 2009, Torsten Dreyer wrote:
> > Hello,
> >
> > What happen now with the Cockpit view
> > Getting now the cockpit cutted
>
> That's the near clipping pane,
> you might want to add
>   
> 
>   
> 0.1
>   
> 
>   
>
> in your model-set.xml
>
> Torsten
>
> > In addition to it , i have never seen,  clouds so well displayed in
> > reality, look like soldiers in parade :)
> > this made laughing, guy whom i tried to demonstrate FG.   :(  :(
>
> Cloudstreets - glider pilots love these ;-)
>
> Torsten
>
>
Thanks, 
the problem is coming up to most of the Aircrafts
For instance c172p, do they have to modified too  ? 
That will be a lot of work  :( 


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Very bad surprise with last FG cvs

[gerard robin]

On vendredi 09 janvier 2009, gerard robin wrote:
> On vendredi 09 janvier 2009, Torsten Dreyer wrote:

> >
> > That's the near clipping pane,
> > you might want to add
> >   
> > 
> >   
> > 0.1
> >   
> > 
> >   
> >
> > in your model-set.xml
> >
> > Torsten
> >

> >
> > Torsten
>
> Thanks,
> the problem is coming up to most of the Aircrafts
> For instance c172p, do they have to modified too  ?
> That will be a lot of work  :(

 Or, why don't we have such parameter   within preference.xml file ?
 then any cockpit  will come back like before, without any missing part.

Cheers
-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Very bad surprise with last FG cvs

[gerard robin]

On vendredi 09 janvier 2009, Tim Moore wrote:
> Frederic Bouvier wrote:
> > - "gerard robin" a écrit :
> >> On vendredi 09 janvier 2009, Torsten Dreyer wrote:
> >>>> Hello,
> >>>>
> >>>> What happen now with the Cockpit view
> >>>> Getting now the cockpit cutted
> >>>
> >>> That's the near clipping pane,
> >>> you might want to add
> >>>   
> >>> 
> >>>   
> >>> 0.1
> >>>   
> >>> 
> >>>   
> >>>
> >>> in your model-set.xml
> >>>
> >>> Torsten
> >>>
> >>>> In addition to it , i have never seen,  clouds so well displayed
> >>
> >> in
> >>
> >>>> reality, look like soldiers in parade :)
> >>>> this made laughing, guy whom i tried to demonstrate FG.   :(  :(
> >>>
> >>> Cloudstreets - glider pilots love these ;-)
> >>>
> >>> Torsten
> >>
> >> Thanks,
> >> the problem is coming up to most of the Aircrafts
> >> For instance c172p, do they have to modified too  ?
> >> That will be a lot of work  :(
> >
> > This is part of Tim's work to make shadows usable.
> >
> > -Fred
>
> Can we all live with a default near plane value of .25? I'll check that in
> tonight. In the meantime, you can set the property on the command line.
>
> Tim
>
>

Just tested, and working we may have it in  preferences.xml file or 
within .fgfs/preferences.xml .
Then, instead of modification within source ..this could be the naswer


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] GL_COLOR_MATERIAL error

[gerard robin]

Hello,
I get now that  error  ( it is only a warning) 

Error: Setting mode 'GL_COLOR_MATERIAL' via osg::StateSet::setMode(mode,value) 
ignored.
   The mode 'GL_COLOR_MATERIAL' is set by the osg::Material 
StateAttribute.
   Setting this as a mode fools osg's State tracking.

Where do i must look for,  in oder to solve it   ?

Using OSG 2.75  and yesterday CVS 

BTW: since it is only a warning i can live with it , however i would be better 
to avoid it .

Thanks

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] new JSBSim CVS for FlightGear?

[gerard robin]

On dimanche 11 janvier 2009, Erik Hofman wrote:
> I was wondering if this would be a good time to update JSBSim again or
> would it be better to hold off a bit?
> Ron Jensen did update the engine model quite a bit which is good for
> accuracy but it might introduce a few problems here and there.
>
> Erik
>

Hello Erik,
I vote yes , you could update, since these Engine update are very  accurate, 
and necessary.
I have some Piston Engine Propellers aircraft which could get profit of it.

Cheers 


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] The Caudron C684

[gerard robin]

Hello,

On request of Guillaume Chauvat  i have just committed an update of his 
wonderful Caudron C684.
I  do like that model and recommend  it  :) .

Cheers
-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] new JSBSim CVS for FlightGear?

[gerard robin]

On dimanche 11 janvier 2009, Erik Hofman wrote:
> gerard robin wrote:
> > Hello Erik,
> > I vote yes , you could update, since these Engine update are very 
> > accurate, and necessary.
> > I have some Piston Engine Propellers aircraft which could get profit of
> > it.
>
> I did discover this requires updates to the engine configuration files
> and since there seems to be a binary only bug-fix release pending this
> might not be desirable.
>
> Erik

If i understand very well, a binary only bug-fix, is very important regarding 
FG, and any consequence on the FDM is not a problem ( was the case before 
when Ron started to update that code).

In any case we will have to update the models today or "tomorrow" that is the 
price of the progress, you better know it than i can do.

As far i can understand FG is today being upgraded, on several ways, and we 
are still waiting for OSG 2.8 stable, which could make coming up some other 
surprises. 

Cheers

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] new JSBSim CVS for FlightGear?

[gerard robin]

On dimanche 11 janvier 2009, Melchior FRANZ wrote:
> * Erik Hofman -- Sunday 11 January 2009:
> > I was wondering if this would be a good time to update JSBSim
> > again or would it be better to hold off a bit?
>
> If an update means having to update all JSBSim aircraft (configs),
> then I'd wait until we have released 1.9.1 or decided that we
> won't release one.

Ho, 
Which Aircraft is involved, but the c172 ?  and it wants a lot of 
improvements.
As far i understood most of the Aircraft which were choose to be in the the 
data file package are YASIm  
 
>
> Otherwise people would have to update all their JSBSim aircraft,
> for a minor bugfix release, which is the most user-unfriendly
> thing we could do.
>
> If there are no changes to aircraft necessary or only to very
> few, then I'd say "go ahead".
>
> m.

Cheers
-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] new JSBSim CVS for FlightGear?

[gerard robin]

On dimanche 11 janvier 2009, Erik Hofman wrote:
> gerard robin wrote:
> > On dimanche 11 janvier 2009, Melchior FRANZ wrote:
> >> * Erik Hofman -- Sunday 11 January 2009:
> >>> I was wondering if this would be a good time to update JSBSim
> >>> again or would it be better to hold off a bit?
> >>
> >> If an update means having to update all JSBSim aircraft (configs),
> >> then I'd wait until we have released 1.9.1 or decided that we
> >> won't release one.
> >
> > Ho,
> > Which Aircraft is involved, but the c172 ?  and it wants a lot of
> > improvements.
> > As far i understood most of the Aircraft which were choose to be in the
> > the data file package are YASIm
>
> Even if it requires one aircraft from the base package to be updated it
> would be bad I think. I'll hold it off for a while then.
>
> Erik
>

Unfortunately, holding that update means that you are holdings other 
improvements which were done recently: viscosity ? engine thrust ?  

:( :( :(   



-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FlightGear 1.9.1

[gerard robin]

On dimanche 11 janvier 2009, Durk Talsma wrote:
> Hi,
>
> Just a quick question. As far as I'm concerned, we'll be doing a 1.9.1 bug
> fix release soon. I would just like to get an impression how our progress
> is on the various problems that have been reported. I know that the "black
> box" problem is fixed now, but how are we doing on the other issues. In
> particular, some people seem to have reported that FlightGear got stuck in
> an endless scenery loading loop. Do we already have a handle on that?
>
> I also know that various people,  have reported other bugs. I am under the
> impression that most of these are actually problems that need to be
> addressed as part of our normal development cycle and not immediate
> showstoppers.
>
> As for a time frame, I'm thinking about mid- to late January, and I would
> indeed recommend that major updates to important system are held off until
> we have released 1.9.1. I can't guarantee a firm timeline yet, because
> temperatures have dropped below freezing, which means I spend my weekends
> ice skating. Rest assured, it's never freezing for extended periods of
> time, so this won't hold up the release indefinitely.
>
> Cheers,
> Durk
>

Hello Durk,
Are you confusing speed and quality ?
What about waiting for a stable OSG version ?
Are you sure we won't get any surprise with it ?
OR do you intend to deliver an other version behind 1.9.1.1.9.2
On our side we don't have yet built the  FG 1.9.
We can only notice that there is still with CVS that ugly blue edge  with 3D 
clouds.
here 
http://pagesperso-orange.fr/GRTux/3DClouds-blue_edge.jpg

And these strange messages on the console when loading some aircrafts

Error: Setting mode 'GL_COLOR_MATERIAL' via osg::StateSet::setMode(mode,value) 
ignored.
   The mode 'GL_COLOR_MATERIAL' is set by the osg::Material 
StateAttribute.
   Setting this as a mode fools osg's State tracking.
Error: Setting mode 'GL_COLOR_MATERIAL' via osg::StateSet::setMode(mode,value) 
ignored.
   The mode 'GL_COLOR_MATERIAL' is set by the osg::Material 
StateAttribute.
   Setting this as a mode fools osg's State tracking.
Error: Setting mode 'GL_COLOR_MATERIAL' via osg::StateSet::setMode(mode,value) 
ignored.
   The mode 'GL_COLOR_MATERIAL' is set by the osg::Material 
StateAttribute.
   Setting this as a mode fools osg's State tracking.


Cheers




-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GL_COLOR_MATERIAL error

[gerard robin]

On dimanche 11 janvier 2009, Frederic Bouvier wrote:
> GL_COLOR_MATERIAL

I first got it from MP.

 Without MP for instance, i do use some OSG objects which take that coding 
..
binName RenderBin
GL_LIGHTING OFF
GL_COLOR_MATERIAL ON
GL_BLEND ON
.
It could be only a problem due to the  objects.osg loading

I will dig further , however it seems coming now with some recent update  from 
Tim.

Regards
-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GL_COLOR_MATERIAL error

[gerard robin]

On dimanche 11 janvier 2009, Frederic Bouvier wrote:
> gerard robin a écrit :
> > On dimanche 11 janvier 2009, Frederic Bouvier wrote:
> >> GL_COLOR_MATERIAL
> >
> > I first got it from MP.
> >
> >  Without MP for instance, i do use some OSG objects which take that
> > coding ..
> > binName RenderBin
> > GL_LIGHTING OFF
> > GL_COLOR_MATERIAL ON
> > GL_BLEND ON
> > .
> > It could be only a problem due to the  objects.osg loading
> >
> > I will dig further , however it seems coming now with some recent update 
> > from Tim.
> >
> > Regards
>
> reproduced with the catalina in fgrun. So if I understand it correctly,
> all you have to do is to remove the offending line in the osg files
>
> -Fred

Yes you are right , i only wonder on about the  consequences on others OSG 
objects, since i don't understand everything  :(  regarding the recent Tim 
updates.

Will  it be  possible to go on with a mixing of .osg models and .ac models ? 

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GL_COLOR_MATERIAL error

[gerard robin]

On dimanche 11 janvier 2009, Frederic Bouvier wrote:
> gerard robin a écrit :
> > On dimanche 11 janvier 2009, Frederic Bouvier wrote:
> >> gerard robin a écrit :
> >>> On dimanche 11 janvier 2009, Frederic Bouvier wrote:
> >>>> GL_COLOR_MATERIAL
> >>>
> >>> I first got it from MP.
> >>>
> >>>  Without MP for instance, i do use some OSG objects which take that
> >>> coding ..
> >>>   binName RenderBin
> >>> GL_LIGHTING OFF
> >>> GL_COLOR_MATERIAL ON
> >>> GL_BLEND ON
> >>> .
> >>> It could be only a problem due to the  objects.osg loading
> >>>
> >>> I will dig further , however it seems coming now with some recent
> >>> update from Tim.
> >>>
> >>> Regards
> >>
> >> reproduced with the catalina in fgrun. So if I understand it correctly,
> >> all you have to do is to remove the offending line in the osg files
> >>
> >> -Fred
> >
> > Yes you are right , i only wonder on about the  consequences on others
> > OSG objects, since i don't understand everything  :(  regarding the
> > recent Tim updates.
> >
> > Will  it be  possible to go on with a mixing of .osg models and .ac
> > models ?
>
> I don't see the relationship between Tim's update and the presence of
> OSG models. By the way, the OSG format seems to have a Material
> directive that the warning message hint.
>
> -Fred

OK, i will go on, and remove the faulty lines for these specific objects.

BTW: it would be nice to know how to catch the involved objects with these 
messages.
osgDB ac3d reader: detected surface with less than 3 vertices!
osgDB ac3d reader: detected surface with less than 3 vertices!
osgDB ac3d reader: detected surface with less than 3 vertices!


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] new JSBSim CVS for FlightGear?

[gerard robin]

On dimanche 11 janvier 2009, Erik Hofman wrote:
> gerard robin wrote:
> > On dimanche 11 janvier 2009, Melchior FRANZ wrote:
> >> * Erik Hofman -- Sunday 11 January 2009:
> >>> I was wondering if this would be a good time to update JSBSim
> >>> again or would it be better to hold off a bit?
> >>
> >> If an update means having to update all JSBSim aircraft (configs),
> >> then I'd wait until we have released 1.9.1 or decided that we
> >> won't release one.
> >
> > Ho,
> > Which Aircraft is involved, but the c172 ?  and it wants a lot of
> > improvements.
> > As far i understood most of the Aircraft which were choose to be in the
> > the data file package are YASIm
>
> Even if it requires one aircraft from the base package to be updated it
> would be bad I think. I'll hold it off for a while then.
>
> Erik


Hello Erik,
I have just updated within FG CVS the engines regarding the model that i am 
working on.
These engines are now running with the the last update from Ron which is in 
the JSBSim CVS repo.
I guess that you were talking about it.
I can notice that is not a bug fix  but a better way to define the Piston 
Engine.
Only the the Supercharger must be improved/included in it.

So i don't see any bad reason to not to update FG with it.

Cheers





-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] new JSBSim CVS for FlightGear?

[gerard robin]

On lundi 12 janvier 2009, Erik Hofman wrote:
> gerard robin wrote:
> > Hello Erik,
> > I have just updated within FG CVS the engines regarding the model that i
> > am working on.
> > These engines are now running with the the last update from Ron which is
> > in the JSBSim CVS repo.
> > I guess that you were talking about it.
> > I can notice that is not a bug fix  but a better way to define the Piston
> > Engine.
> > Only the the Supercharger must be improved/included in it.
> >
> > So i don't see any bad reason to not to update FG with it.
>
> The problem I had with the default c172 was that with the current engine
> configuration file the engine would stall when the throttle is set to a
> minimum. I don't think that would be desirable.
> Anyhow it looks like the delay will be minimum (it's not freezing
> anymore :))
>
> Erik
>

I could be wrong but Ron gave, with the FGPiston update, a c172 Engine update 
(eng_io320.xml) .
According to the result it is very accurate.
Look at the mail :


Re: [Jsbsim-devel] Throttle Patch to FGPiston
 Date : 2009-01-03 16:01
 De : Ron Jensen 



Sorry i don't have the link only the content.

In any case it is an improvement for the c172



-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] new JSBSim CVS for FlightGear?

[gerard robin]

On lundi 12 janvier 2009, Erik Hofman wrote:
> gerard robin wrote:
> > I could be wrong but Ron gave, with the FGPiston update, a c172 Engine
> > update (eng_io320.xml) .
> > According to the result it is very accurate.
>
> True, but this requires a base package update to work correctly. Which
> is better to delay a few days so the binary only bugfix release can get
> released.
>
> Erik
>

Ouups
 sorry i thought that we could get profit, at least with FG 1.9,  of a nice 
and huge update of the c172 , which is today wrong and broken  ( reffering to 
the large talk on that mail list last year ).





-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] new JSBSim CVS for FlightGear?

[gerard robin]

On lundi 12 janvier 2009, Stefan Seifert wrote:

>
> I think this is a very good example of why regular releases are good.
>
> When the next release is already in sight, the pressure to push "huge
> updates" into maintenance releases lowers considerably. So, yes, it would
> be nice to have a much better c172 now, but it's still ok, to see it fly in
> a few months, perhaps even still better.
>
> And related: having release branches would be at least equally nice. As of
> now CVS head does not even represent the current development version
> anymore, because people are holding back patches not fit for a maintenance
> release. As branching in CVS is very expensive, we now have another reason
> to migrate to _any_ other VCS.
>
> So, is there anything I could do to help speeding up this migration?
>
> Stefan

I agree, we want  branches , with at least one which represents the real 
current development.
We don't have free time any time. We are able to contribute only when that 
free time is there.

On my "poor" side, for instance, i cannot wait for updates which will come "a 
day"  (sync with JSBSim cvs) , i do have my own FG updated, and i do work 
with that local version, deciding to update within FG  the models  that i am 
working on, when i have some free time.
In addition to it,  doing so,  spare time (time is money :) ).

I may hope that a day these models will be sync with FG.

I am not expert, but i feel it is missing a real coordinator to manage both 
branches =>  current devel, and  => maintenance release.

Cheers

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GL_COLOR_MATERIAL error

[gerard robin]

On dimanche 11 janvier 2009, Frederic Bouvier wrote:
> gerard robin a écrit :
> > On dimanche 11 janvier 2009, Frederic Bouvier wrote:
> >> gerard robin a écrit :
> >>> On dimanche 11 janvier 2009, Frederic Bouvier wrote:
> >>>> gerard robin a écrit :
> >>>>> On dimanche 11 janvier 2009, Frederic Bouvier wrote:
> >>>>>> GL_COLOR_MATERIAL
> >>>>>
> >>>>> I first got it from MP.
> >>>>>
> >>>>>  Without MP for instance, i do use some OSG objects which take that
> >>>>> coding ..
> >>>>> binName RenderBin
> >>>>> GL_LIGHTING OFF
> >>>>> GL_COLOR_MATERIAL ON
> >>>>> GL_BLEND ON
> >>>>> .
> >>>>> It could be only a problem due to the  objects.osg loading
> >>>>>
> >>>>> I will dig further , however it seems coming now with some recent
> >>>>> update from Tim.
> >>>>>
> >>>>> Regards
> >>>>
> >>>> reproduced with the catalina in fgrun. So if I understand it
> >>>> correctly, all you have to do is to remove the offending line in the
> >>>> osg files
> >>>>
> >>>> -Fred
> >>>
> >>> Yes you are right , i only wonder on about the  consequences on others
> >>> OSG objects, since i don't understand everything  :(  regarding the
> >>> recent Tim updates.
> >>>
> >>> Will  it be  possible to go on with a mixing of .osg models and .ac
> >>> models ?
> >>
> >> I don't see the relationship between Tim's update and the presence of
> >> OSG models. By the way, the OSG format seems to have a Material
> >> directive that the warning message hint.
> >>
> >> -Fred
> >
> > OK, i will go on, and remove the faulty lines for these specific objects.
>
> Or consider adding a Material directive inside the StateSet directive.
> Search for Material in .osg models of the OpenSceneGraph-data collection.

You  are right, i must upgrade my old know  how , i will dig into it.
>
> > BTW: it would be nice to know how to catch the involved objects with
> > these messages.
> > osgDB ac3d reader: detected surface with less than 3 vertices!
> > osgDB ac3d reader: detected surface with less than 3 vertices!
> > osgDB ac3d reader: detected surface with less than 3 vertices!
> > 
>
> This is an OSG message. One should submit a patch that would print the
> name of the object.

Mr One has never answered to that request, i think that he has left FG 
devel  :)
Then, we will go on,  living with that bunch of stupid messages.
Fortunately, it is only warning.
>
> -Fred



-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FG ocean water shader / water region issue.

[gerard robin]

On mercredi 14 janvier 2009, James Turner wrote:
> On 14 Jan 2009, at 11:16, Martin Spott wrote:
> >> As far as I know - there's no diference between solid and liquid
> >> surfaces
> >> from FG/SG point of view. In other words
> >> - rivers, lakes, ocean are a part of TerraGear scenery (except
> >> OceanTiles
> >> for non existent BTG-s of course).
> >
> > Right, in the current Terrain file format we just define a surface
> > type
> > name and leave it to FlightGear to look the characteristics up in the
> > 'materials.xml' file.
> > Note that we're currently dealing with at least two different types of
> > 'water areas', "Lake" and "Ocean", and we're telling between different
> > seasons. Thus, whichever approach you're taking, please don't simply
> > rely on water areas being represented by "Ocean". One day we might
> > even
> > define the surface characteristics in the Terrain tiles instead of
> > looking up in the 'materials.xml' 
>
> I've idly wondered about pulling the water out of the generated
> scenery, and instead creating 'ground' down to the low tide line. The
> water surface could then be created at runtime, allowing for tides,
> waves, and other effects depending on the GPU/CPU power available. For
> this to work, we'd need some way to extrapolate the coastal gradient
> down to the low water mark, which I suppose is tricky. Then there's
> the issue of tidal rivers - again I guess our shoreline / river data
> doesn't encode the high and low- water lines.
>
> Oh, and there's the 'Holland' problem as well - so there needs to be
> some way to clip out the water surface - possibly the same way lakes
> would be handled, though.
>
> James
>
In addition to that tide effect, which would be nice.

That would solve the following:
Since we are still having that ugly level difference ( look like a tsunami)  
from the generic sea  tile to the sea which is close to the coastline (part 
of the scenery) since the connections becomes wrong. 
Never solved with OSG. was right with PLIB.

The consequence is that with  seaplane it will be difficult to take off, if we 
are in that transition area, which could be close to the coastline ( for 
instance abroad Toulon )
An other consequence, with a moving Ai ship  ( like Carrier) she is flying 
over the sea  or sinking, ( depending on the position she is situated).

Cheers
 

Cheers


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] proposed 1.9.1

[gerard robin]

On jeudi 15 janvier 2009, Csaba Halász wrote:
> On Thu, Jan 15, 2009 at 12:31 AM, Tim Moore  wrote:
> > There has been a flurry of bug fixes in the last few days. I want to
> > review the state of the maint branches in the simgear and flightgear git
> > repositories and suggest that they would now be a good source for a 1.9.1
> > bug fix release. I've been fairly conservative and have been only
> > checking fixes into those branches that fix reported or potential bugs.
>
> There are some pending NaN problems I have reported, but have not been
> fixed. And users are complaining about IntersectionVisitor/CullVisitor
> flooding console with messages about NaNs ;)

AND what about clouds with blue_edge  ?

http://pagesperso-orange.fr/GRTux/3DClouds-blue_edge.jpg

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] proposed 1.9.1

[gerard robin]

On jeudi 15 janvier 2009, James Turner wrote:
> On 14 Jan 2009, at 23:56, gerard robin wrote:
> > AND what about clouds with blue_edge  ?
> >
> > http://pagesperso-orange.fr/GRTux/3DClouds-blue_edge.jpg
>
> I'd say, not worth delaying 1.9.1 for - unless there is a low-risk
> fix, which I doubt, since it appears to be a sorting issue. 'Clouds
> look a bit wrong' is not the same magnitude of issue as 'I can't run
> 1.9.0'.
>
> James

May be it would be better  to have 2D cloud as default in the preferences.xml 

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FG ocean water shader / water region issue.

[gerard robin]

On vendredi 16 janvier 2009, Martin Spott wrote:
> James Turner wrote:

> To the current state we have a coastline around each 'isolated'
> continent or island which is either made from a single closed polygon
> (which could be GSHHS) or from the outline around a couple of adjacent
> polygons (VMap0 political boundaries). To get an overview, please check
> here:
>
>   http://wiki.osgeo.org/wiki/Geodata_Repository#PostGIS_serving_vector_data
>
> This coastline is the basic factor for a simple principle: Everything
> inside this coastline is counted as ground, the entire area outside the
> coastline is "Ocean". The same principle applies to lakes - just in the
> reverse order: Everything inside the lake shoreline is water.
>
> So, even if our STRM elevation grid would indicate some sort of
> elevated ground outside our coastline, it's going to get clipped out
> due to the given principle. In contrast, if there's no elevation data
> for an area inside the coastline, then the ground is still going to get
> extended in accordance with the coastline   but at sea level.
> There's a nice example for these corner cases if you approach RWY 24 at
> TNCE in the 1.0.1 Scenery.
>
> I'm proposing a similar but somehow opposing schema (talking is cheap  ;-)
> Let us have the seabed modelled using bathymetry data, clipped against
> the same coastline which we're using to clip the ground elevation,
> limit the maximum 'elevation' of the seabed to the elevation of the
> respective coastline, which is presumably at MSL for all ocean
> shorelines - or the individual elevation of the respective lake.
> Probably limit the seabed elevation to a few centimetres below to allow
> for some nice waves 
> I don't see any reason why and how this approach would set KSFO under
> water.
>
> > Also, is global (even crude) coastal bathymetry data available?
>
> Yes, I even had a copy of global bathymetry data on my local disk few
> years ago, but lost it due to sort of a crash (well, the data is still
> sitting there, but I have to re-assemble the partitions before I'm able
> to read it).
>
> Cheers,
>   Martin.


I did not understood everything about the content of that topic, since the 
technical  which is involved is "flying" over of my low know how.

I would like only say ( again , because said before) that the coastline which 
is close to my favorite area , the  French coastline on Mediterranean sea, 
was better with the 9.8 scenery.
It is sure that the last version is mostly better  than the 1.0,  however it 
is not so right than it was with the old 9.8 version.

I understand that making the scenery is a very difficult work. From the data 
which which are freely available it is difficult to get the same quality that 
we can have now with google 3D or IGN (France).

In addition to it,  i worry that we are not able to get the right connection 
from the generic sea tile to the coastline tile ( difference of level)

So, before to spend some time to try to develop any water shader, it would be 
better to invest time to try to get a consistent sea surface.

Cheers 

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FG ocean water shader / water region issue.

[gerard robin]

On vendredi 16 janvier 2009, Martin Spott wrote:
> gerard robin wrote:
> > So, before to spend some time to try to develop any water shader, it
> > would be better to invest time to try to get a consistent sea surface.
>
> Go ahead,
>   Martin.

:) :) :) thanks for the authorization

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FG ocean water shader / water region issue.

[gerard robin]

On vendredi 16 janvier 2009, Martin Spott wrote:
> Hi Tim,
>
> Tim Moore wrote:
> > Some of the sea surface problems may be partially my fault. In August
> > 2007 I added more polygons to the generic ocean tile to more closely
> > match the curvature of the earth, in order to prevent AI ships from
> > hovering several meters above the surface. I'm not sure this was ever
> > communicated to the scenery team.

Thanks Tim 
>
> I suspect the communication agent has failed  ;-)
> Does your change actually cause a difference between a) the 'border'
> between ground and ocean as defined in the Scenery tiles and b) its
> visual representation in FlightGear ? If so, of which nature is this
> difference ?
>
>   Martin.

Yes it is visual and seen like a wall by the groundcache, so here the seaplane 
wont be able to go through.
Here the original snapshot that i did,  when discovering the problem (august 
2007)
http://pagesperso-orange.fr/GRTux/tsunami.jpg

The difference depends on the position along that"border"   since the 
generic tile has a curvatureand the sea coastline tile is FLAT.

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] really dark clouds

[gerard robin]

On vendredi 16 janvier 2009, Martin Spott wrote:
> Occasionally I notice the current clouds getting _really_ dark when
> they are getting close to the ground (EGKA RWY 20):
>
>   http://foxtrot.mgras.net/bitmap/FGFS/EGKA-161250Z.png
>
> The corresponding METAR is:
>
>   EGKA 161250Z 20011KT 0800 -RADZ FG SCT001 OVC002 07/07 Q1015
>
>   Martin.

You are right i noticed it elswhere, may be an unforecast solar :) eclipse

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Terrain errors report

[gerard robin]

On samedi 17 janvier 2009, Martin Spott wrote:
> Brian Schack wrote:
> > There are several huge and very unnatural walls in the Himalayas, both
> > running NS and EW.  I'll give the line of latitude or longitude that
> > the wall runs along, and the end coordinates of the walls:
>
> The underlying SRTM elevation data is known to have many voids in the
> Himalayan area and a reasonable explanation _might_ be that the void
> filling in TerraGear doesn't provide too realistic results.
> For your own experience, you'll find a copy of the respective elevation
> raster here as a geo-referenced 1x1 degree TIFF image:
>
>  
> ftp://ftp.ihg.uni-duisburg.de/GIS/GISData/SRTM/version2/GeoTIFF/Eurasia/N28
>E083.tif
>
> Note that these images have a 16-bit grayscale channel, therefore
> simple "visual debugging" on a typical PC screen might be quite tricky
> due to limited colour depth. In order to get a better clue about the
> reported errors I'd consider it as being highly desirable looking at a
> similar error at a place which is located at a much lower elevation.
>
> Cheers,
>   Martin.
Because of some reason i mostly do use the old FG 0.9.8  scenery
I have flown over Himalaya mountains looking for hole, wall or flat part , 
nothing.  :)  only mountains  :)

here snapshots of the Everest
http://pagesperso-orange.fr/GRTux/f16-everest_1.jpg
http://pagesperso-orange.fr/GRTux/f16-everest_2.jpg

So older data were right.

Cheers
-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Terrain errors report

[gerard robin]

On mardi 20 janvier 2009, gerard robin wrote:
> On samedi 17 janvier 2009, Martin Spott wrote:
> > Brian Schack wrote:
> > > There are several huge and very unnatural walls in the Himalayas, both
> > > running NS and EW.  I'll give the line of latitude or longitude that
> > > the wall runs along, and the end coordinates of the walls:
> >
> > The underlying SRTM elevation data is known to have many voids in the
> > Himalayan area and a reasonable explanation _might_ be that the void
> > filling in TerraGear doesn't provide too realistic results.
> > For your own experience, you'll find a copy of the respective elevation
> > raster here as a geo-referenced 1x1 degree TIFF image:
> >
> >
> > ftp://ftp.ihg.uni-duisburg.de/GIS/GISData/SRTM/version2/GeoTIFF/Eurasia/N
> >28 E083.tif
> >
> > Note that these images have a 16-bit grayscale channel, therefore
> > simple "visual debugging" on a typical PC screen might be quite tricky
> > due to limited colour depth. In order to get a better clue about the
> > reported errors I'd consider it as being highly desirable looking at a
> > similar error at a place which is located at a much lower elevation.
> >
> > Cheers,
> > Martin.
>
> Because of some reason i mostly do use the old FG 0.9.8  scenery
> I have flown over Himalaya mountains looking for hole, wall or flat part ,
> nothing.  :)  only mountains  :)
>
> here snapshots of the Everest
> http://pagesperso-orange.fr/GRTux/f16-everest_1.jpg
> http://pagesperso-orange.fr/GRTux/f16-everest_2.jpg
>
> So older data were right.
>
> Cheers

In addition, the map of that area which was done with atlas
http://pagesperso-orange.fr/GRTux/e086n27.png
http://pagesperso-orange.fr/GRTux/e086n28.png
http://pagesperso-orange.fr/GRTux/e087n27.png
http://pagesperso-orange.fr/GRTux/e087n28.png

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Terrain errors report

[gerard robin]

On mardi 20 janvier 2009, Martin Spott wrote:
> gerard robin wrote:
> > So older data were right.
>
> I wonder how you managed to draw a conclusion even before the error has
> been identified properly,
>
>   Martin.

 i only have eye, a computer, and archives

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Terrain errors report

[gerard robin]

On mardi 20 janvier 2009, Martin Spott wrote:
> gerard robin wrote:
> > On mardi 20 janvier 2009, Martin Spott wrote:
> > > gerard robin wrote:
> > >
> > > I wonder how you managed to draw a conclusion even before the error has
> > > been identified properly,
> >
> >  i only have eye, a computer, and archives
>
> So, did you create screenshots from the 1.0.1 Scenery as well as the
> 0.9.8 Scenery that allow to identify the differences between the two
> Scenery releases ?
>
>   Martin.

No i did not , since i get some difficulties with the  coastline and islands 
of 1.0.1 . (which explain that i am longer using these old scenery)
However, i could do it, the Himalayan area being longer far from the sea 
side  :)
The best would be to do build the map with the original Atlas map, in order to 
get the right comparison.

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] CVS: data/Aircraft/Boeing314 Boeing314A.xml, 1.5, 1.6

[gerard robin]

On mercredi 21 janvier 2009, Melchior FRANZ wrote:
> * Erik Hofman -- Wednesday 21 January 2009:
> [...]
>
> > Modified Files:
> > Boeing314A.xml
> > Log Message:
> > Add the license statement
> >
> > + 
> > +   GPL (General Public License)
> > +   http://www.gnu.org/licenses/gpl.html
> > + 
> > + 
> > + [...]This model
> > + is not to be sold.
> > + 
>
> That's impossible! The GPL explicitly allows selling software,
> and it does *not* allow to add restrictions!
>
> So, either the "is not to be sold" has to be removed, or the
> aircraft shall be removed from CVS.
>
> m.
>
I was told by a layer,  since we are writing that the model is copyrighted 
protected under Licence GPLV2 , we may write anything we want as addons 
regarding the protection,  these addons won't be taken in account , and one 
may ignore it.

Are we wrong ?

Cheers
  



-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Licensing and disclaimers for aircraft models

[gerard robin]

On mercredi 21 janvier 2009, Jon S. Berndt wrote:
> > Ah sorry, that slipped my attention, you are right.
> > I'll ask Jon about it.
> >
> > Erik
>
> We should discuss this, then, because the impacts may be more far reaching.
> I asked the Boeing licensing people some time ago about our flight models.
> They were OK with us creating models, but were not OK with the models being
> sold as a "Boeing" model. My interpretation of that is that the flight
> models cannot be advertised as "Boeing" models in any way that might
> indicate Boeing endorses it or is involved, and the name Boeing is also
> trademarked, I believe.
>
> Now, there is probably some wiggle room there, since the GPL allows a
> variety of things and interpretations vary. I would think that as long as
> the models are not themselves marketed as Boeing endorsed products - and no
> indication  or misleading labeling is used to indicate that they are Boeing
> endorsed - then we're probably OK. That may involve changing the name to
> B314 instead of Boeing314, or something similar. It also may involve
> requiring that anyone who is selling FlightGear for profit (with value
> added material, for instance) not include the Boeing314, Boeing 737, 747,
> etc. Another solution is to keep such aircraft as the Lockheed f-16, f-22,
> etc. Boeing aircraft, Airbus aircraft, etc. all on a separate server with
> special license statements.
>
> I'm not trying to be difficult. But, I've done the work, contacted the
> manufacturer, asked permission, and gotten an answer. This likely applies
> to more than the Boeing 314. Before making rash and sweeping statements,
> this needs to be given some careful thought. A disclaimer is the least that
> should be included in each and every aircraft file, IMHO.
>
> This action is meant to protect people and companies both. There have been
> inquiries by companies and some actions taken in the not too distant past
> that has lead me to be much more careful.
>
> You should be too. Discussion welcomed.
>
> Jon
>

Won't it be possible to leave to the potential shop which wants to sell 
our "products "to assume the responsibility of it. Since we don't sell 
anything.

We may go on  to keep our model and our code protected under GPL license.

Only an information regarding the copyright for such private Name: 
Boeing..Lockheed.. and so on could be necessary.

These  addons won't be a restriction only an information.

Cheers





-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] CVS: data/Aircraft/Boeing314 Boeing314A.xml,

[gerard robin]

On mercredi 21 janvier 2009, Martin Spott wrote:
> Erik Hofman wrote:
> > Update of /var/cvs/FlightGear-0.9/data/Aircraft/Boeing314
> > In directory baron.flightgear.org:/tmp/cvs-serv11895
> >
> > Modified Files:
> > Boeing314A.xml
> > Log Message:
> > Add the license statement
> >
> > + This simulation model is not endorsed by the manufacturer.
> > This model + is not to be sold.
>
> Melchior FRANZ wrote:
> > http://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowMoney
> >
> > "Does the GPL allow me to sell copies of the program for money?
>
> You see the difference ? Hey, usually MF is unnatural over-picky about
> everyone's statements and/or ideas, now he breaks with his own habits.
>
> Nice,
>   Martin.

Cool,  Martin
Nobody, here and everywhere  is perfect  :)

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] flyby volume (was: Doppler volume)

[gerard robin]

On jeudi 22 janvier 2009, Melchior FRANZ wrote:
> * John Denker -- Thursday 22 January 2009:
> > On 01/22/2009 06:05 AM, Melchior FRANZ wrote:
> > > But it depends on the frequency pattern, no? So we'd need to
> > > analyze the spectrum ... time to use libfftw3.
> >
> > No, the 1/r^2 attenuation is independent of frequency.  No FFT
> > required.
>
> The law is the same, but the distances aren't. Lower frequency
> travels farther.

Not fully right. 
Only right when high frequencies  are  stopped by objects. Low frequencies 
could go over, and farther
The wider and the heavier  the objects are,   the lower the frequency may only 
go through.
If there is no object between the emissive sound and the recever/listener  the 
full  auditive band ( 20/2 hz)  is traveling to the same distance.

> I don't think that's irrelevant. An automatic 
> calculation wouldn't know of which kind the sound is.
>
> m.
>




-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] flyby volume

[gerard robin]

On jeudi 22 janvier 2009, Melchior FRANZ wrote:
> * gerard robin -- Thursday 22 January 2009:
> > On jeudi 22 janvier 2009, Melchior FRANZ wrote:
> > > The law is the same, but the distances aren't. Lower frequency
> > > travels farther.
> >
> > Not fully right. Only right when high frequencies  are  stopped
> > by objects.
>
> Yes, and there are enough particles in air to have that effect.
> That's the atmosphere.  :-}
>
> m.

Particles are a filter only for very high frequencies  out of the audible 
range 
Atmosphere  is  the transmitter, without atmosphere there is no sound.


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Licensing and disclaimers for aircraft models

[gerard robin]

On samedi 24 janvier 2009, syd adams wrote:
> I have to agree with the last 2 options  maybe keep a select few to go
> with the release. It would make the first time data update more pleasant
> :).

We had it  (some years ago)  "the first time data update more pleasant" when 
there was a specific directory which contained the stable Aircraft.

Now with more than 230 models within CVS, using model based CVS, is 
impossible, since the newbe has to dig into it in order to find a model 
working, but if he is lucky. 
Getting the right model is a game within the game.

Even me , i am lost  :(


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Flightgear-devel Digest, Vol 33, Issue 26

[gerard robin]

On samedi 24 janvier 2009, BARANGER Emmanuel wrote:

> I am tired of the negative attitudes of some.

Have some rest   :)  :):) 

>
> CVS is a place of study, research, development. It is not there to the
> users. Please.
>
> The stable official FG contains a minimum of aircraft representing a
> wide diversity. That's enough. And there is no place to get lost.
>
> Those who choose to recover the aircrafts CVS do so knowingly. There is
> therefore no criticism to make on this subject. Except, of course, want
> to criticize for the sake of criticism and damage the work of others.
>
> Bests regards. Emmanuel
>
> P.S. "Free software" is also freedom of choice. And more there will be
> planes, more users will have the freedom to choose.



-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Flightgear-devel Digest, Vol 33, Issue 26

[gerard robin]

On samedi 24 janvier 2009, syd adams wrote:

> > Hi Emmanuel ,
>
> My thoughts were to move the "extra" or "non sellable" aircraft out of cvs
> /data , not to erase them completely  I am working on the Boeing 777 ,
> so this issue is of some interest to me 
> Cheers

Hi, Syd 

don't be wrong you were not the Guy 'SOME' whom the insult was launched in 
that talk.

I was ... the guy   :)

My point ( before the "eb-heilja" shout) , was to remind that period when we 
had a specific stable aircraft directory. 
This was an advantage since anybody who wanted an accurate Aircraft, could 
download from it.
CVS has the disadvantage to offer everything from the less achieved (skeleton)  
to the most accurate in the same tin, for instance none of mine is right (and 
some of then do not fly).

Then it is up to the luck to get the good one.
That is not fair for modelers who spend, many, many hours,  to work on a 
model which the accuracy is very hight.

AND, in these coming day, if MSFS is really out, who among the MSFS users 
coming to FG,  looking for an aircraft, will be enough lucky to get an 
achieved model among the 230 ones ?

In addition to my point.
You are right, we could have 
 -a sellable   => fully GPL model  directory
 -a not sellable => not fully GPL model directory

Regarding CVS directory there is no more problem with it, since we can get 
individual aircraft from it  with only a little script

Cheers

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FlightGear 1.9.1

[gerard robin]

On dimanche 25 janvier 2009, Durk Talsma wrote:
> On Sunday 25 January 2009 21:49:21 Jon S. Berndt wrote:
> > I would hope that synching JSBSim would be seamless by now. Of course, it
> > doesn't usually work like that. :-)
>
> The part we considered "risky" was that possibly quite a few aircraft
> needed an update to their configuration files, in order to make use and/or
> function correctly with the latest JSBSim features. This would probably
> require more time than we'd like. At least that is my understanding.
>
> I don't think that anybody would consider a new JSBSim version risky in
> terms of crashing FlightGear or inducing compiler errors. :-)
>
> Cheers,
> Durk
>


In case of the quality  is our target.

http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-January/021991.html


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] The use of models from other formats

[gerard robin]

On samedi 07 février 2009, Durk Talsma wrote:
> Hi Ian,
>
> On Saturday 07 February 2009 11:39:13 FGD ML wrote:
> > 2009/2/7 Arnt Karlsen 
> >
> > > ..ah, that's where I try to help out. ;o)
> >
> > I'm sorry , I have a policy of not accepting cold callers.
>
> I hope you find comfort in the fact that 99% of our fgfs-devel subscribers
> is simply ignoring Arnt. The other 1% is just new to the list. :-) His
> opinions don't carry much (if any) weight here.
>
> I'm not exactly happy that I have to mention this fact, but I've seen
> people go down an endless road to nowhere, when starting a discussion with
> him. So far, all other aspects of the discussion have been courteous and
> professional. I hope you guys can continue that way.
>
> Cheers,
> Durk
>

Durk,
I am just coming back, "close to keyboard".
I can notice your remark which has not the right place here.
What makes you to reject what say  Ant  ? 
Do you think that you are  positive ?

Regards



-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] The use of models from other formats

[gerard robin]

On samedi 07 février 2009, Roy Vegard Ovesen wrote:
> On Saturday 07 February 2009 11:50:57 FGD ML wrote:
> > 2009/2/7 Roy Vegard Ovesen 
> >
> > > On Saturday 07 February 2009 10:22:09 Roy Vegard Ovesen wrote:
> > > > As I said the .lwo file that Blender generated did _not_ contain any
> > > > reference to the texture image, so I don't think that putting the
> > > > image
> > >
> > > in
> > >
> > > > the same path as the .lwo file will work. This could of course be
> > > > because I'm not using Blender correctly, but I think that is
> > > > irrelevant. We want
> > >
> > > to
> > >
> > > > test .lwo files created by LightWave, not .lwo files created by
> > > > Blender.
> > >
> > > Turns out I _did_ use Blender incorrectly.
> >
> > Well there you go!
> >
> > > I managed to create a Borgbox textured with a .png image from the FG
> > > data dir,
> > > and display it correctly in osgviewer. I would really like to repeat
> > > the test
> > > with a .lwo file created with the reference software LightWave. I don't
> > > see using Blender to create .lwo files as a realistic workflow
> >
> > We seem to be agreed there. It's OK for some I guess, I just have a
> > different taste when it comes to getting work done. I tend to like to be
> > able to see more of the job in hand, and far, far less of the interface.
> >
> > Can I take it you can now see the filename(s) in the .lwo? It's normally
> > down towards the end of the file.
>
> Yes, full pathname to the .png image file. There is actually a bug in the
> exporter code that cuts one character from the path string (/home/...
> becomes /hme/...). I also tried to remove the pull path leaving only the
> filename, and copied the image file into the same directory as the .lwo
> file, but that did not work.
>
> > Go grab a copy! At least know how it /can/ be done. I always do that
> > where the maker makes it possible without fuss or gotchas of any kind. I
> > see it as meeting them halfway. It then has it's one chance to impress
> > me, just like anything else gets.
>
> Do you mean grab a copy of LightWave?

Now, I can only confirm the possibility to transfer and use any lwo model in 
FG.
I experienced it , since i am  an "Old   Amiga user" (connected on my local 
network  the computer is still sitting in my office   :)  ), using Lightwave 
and Imagine , for instance among a lot of other objects, my very first 
version of  BlackBird was done with it.
Many years ago when i discovered FG,  i started to convert these objects to ac 
format.
At that time  Blender was not  very accurate.
As far i remember, i probably  used a convertion from lwo to dxf.
Recently i did used Blender to convert again some old models  (Fouga Zephir) 
without problem.


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] "proper" ground reactions (was "YASim & sliding helicopters bug")

[gerard robin]

On vendredi 06 février 2009, Torsten Dreyer wrote:
> > Where is the "proper" gear model patch, Martin?  mail.flightgear.org
> > is down so the archives prior to 2005 are unreachable.  I'm interested
> > in taking a look.
> >
> > I'm also wondering what is stopping you from grabbing a copy of
> > JSBSim, applying the patch, and providing some data to the "powers
> > that be" to validate this "proper" ground reaction model?  If it's as
> > simple as applying a patch, why not spend some time/effort making your
> > case with data rather than simply tossing emails back and forth?  Just
> > a thought.
>
> I think what Martin is referring to can be found here:
> http://developer.berlios.de/projects/openfdm/
>
> Greetings, Torsten
>
Oh,  Eh, Yes

 That OpenFDM  was supposed to be confidential.   :)
Anyhow,   that FDM was very promising   i had done a private F8-E version with 
it which works perfectly.

The ground reaction with it,  is very accurate.
Testing it on a moving Carrier gives the best behaviour 

Cheers

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FG sound files

[gerard robin]

On lundi 09 février 2009, alex wrote:
> Does OpenAL support any other sound file configuration other than .wav?
> I have problems with OpenAL unable to buffer some .wav files but runs fine
> with other .wav files. Does anyone know of a particular reason for this.
> Your thoughts would be appreciated
>
> Alex
>
>
>
> E-mail message checked by Spyware Doctor (6.0.0.386)
> Database version: 5.11630
> http://www.pctools.com/uk/spyware-doctor-antivirus/


Wav format should be with that Window's native definition
here
http://www.sonicspot.com/guide/wavefiles.html#wavefilechunks
or here 
http://ccrma.stanford.edu/courses/422/projects/WaveFormat/

However i experienced a lot of variants of  it.

Among my huge recorded music library, i  have found at least four variants, 
which depends on the recorder which has been used ( Tascam professional, 
Computer with Linux Audacity, Computer with Windows samplers,  Studer numeric 
recorder ...etc )

Sox is the convertion tool which can help.

Cheers




-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Preferred development os

[gerard robin]

On mardi 10 février 2009, Harry Campigli wrote:
> I have used SUSE for years, currently using 10.3. but feel it has "gone
> off" since version 9. However I have always managed to build FG from source
> on it with a bit off mucking around but never Terragear.
>
> For along time I have wondered about Debian. I get the impression a lot of
> FG developers use it. Thus I have installed  the etch verion.  Everything
> from the install worked of the mark. Unlike SUSE.   I managed to get FG
> installed with some small bug in the sound, and still fiddling about with
> terragear compiling. However its early days.
>
>
> Therefore could I float the question amongst FG developers  as which OS is
> most commonly used or preferred as a Flightgear/Terragear development
> system.

I maintain a friend's computer (bi-processor   64 bits AMD) .
I first tried to install Fedora core ( i am using it for many years  on my 
computer 32 bit) , i could not built FG with it.


I found that OpenSUSE was the best solution regarding the requirements.
The 11.1 is a very good version, very stable , for the KDE users, we still 
have the choice in between KDE3 and KDE4 ( which is not accurate ).

What is exactly your problem  with OpenSUSE ?

Cheers


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FG sound files

[gerard robin]

On mardi 10 février 2009, Erik Hofman wrote:
> alex wrote:
> > Does OpenAL support any other sound file configuration other than .wav?
> > I have problems with OpenAL unable to buffer some ..wav files but runs
> > fine with other .wav files. Does anyone know of a particular reason for
> > this.
> > Your thoughts would be appreciated
>
> Like gerard already mentioned, the WAVE file is a container file that
> can handle about anything from 8-bit to 32-bit sound files either
> compressed or uncompressed. It is even possible to store an mp3 file in
> a file with a .wav extension. The alut wav file loader only handles a
> small subset of them; signed 8-bit, unsigned 16-bit, ulaw and alaw
> compressed and as of yesterday also the IMA4 compression type.
>
> Erik
>

Erik is right,

In addition to my "generic" answer.

When i get trouble with a sound file ( which happen very often :( )
I do the following:

I try to load it with Audacity ( at least version, 1.35 )

=>If it load correctly => you can see the curves and you can listen the sound
==>You check the rate ( 8000, 16000, 22050, 44100, 48000, 96000 ) , and 
if  
required you convert to the right rate.
==>You check the  bits PCM ( 8, 16 , 32 float),  and if required you 
convert 
to the right bits PCM value.
==>Then Export the file to WAV format

=>If it do not load correctly, try with sox ( version 1.2) 
The command line for instance to convert the sound file to 48000 rate  24 bits 
PCM is:
sox -S  yoursoundorigin.vaw   -b 24 -r4800  yoursoundconverted.vaw

sox will tel you how was the original format of the sound, and convert it.

Then you can convert again that " yoursoundconverted.vaw" sound to a less rate 
and bit values ( Aircraft sound is not HIFI,  only NOISE :(  )  -r 8000 -b 8 

Doing this,  i have been able to save a lot of live recorded music done with 
an old  digital recorder.

I hope, it should do for you 


Cheers

BTW: you will notice that Audacity  is very accurate since you can improve the 
sound with it, with the filters and effects tools.

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FG sound files

[gerard robin]

On mardi 10 février 2009, gerard robin wrote:
> On mardi 10 février 2009, Erik Hofman wrote:
> > alex wrote:
> > > Does OpenAL support any other sound file configuration other than .wav?
> > > I have problems with OpenAL unable to buffer some ..wav files but runs
> > > fine with other .wav files. Does anyone know of a particular reason for
> > > this.
> > > Your thoughts would be appreciated
> >
> > Like gerard already mentioned, the WAVE file is a container file that
> > can handle about anything from 8-bit to 32-bit sound files either
> > compressed or uncompressed. It is even possible to store an mp3 file in
> > a file with a .wav extension. The alut wav file loader only handles a
> > small subset of them; signed 8-bit, unsigned 16-bit, ulaw and alaw
> > compressed and as of yesterday also the IMA4 compression type.
> >
> > Erik
>
> Erik is right,
>
> In addition to my "generic" answer.
>
> When i get trouble with a sound file ( which happen very often :( )
> I do the following:
>
> I try to load it with Audacity ( at least version, 1.35 )
>
> =>If it load correctly => you can see the curves and you can listen the
> sound ==>You check the rate ( 8000, 16000, 22050, 44100, 48000, 96000 ) ,
> and if required you convert to the right rate.
>   ==>You check the  bits PCM ( 8, 16 , 32 float),  and if required you
> convert to the right bits PCM value.
>   ==>Then Export the file to WAV format
>
> =>If it do not load correctly, try with sox ( version 1.2)
> The command line for instance to convert the sound file to 48000 rate  24
> bits PCM is:
> sox -S  yoursoundorigin.vaw   -b 24 -r4800  yoursoundconverted.vaw
>
> sox will tel you how was the original format of the sound, and convert it.
>
> Then you can convert again that " yoursoundconverted.vaw" sound to a less
> rate and bit values ( Aircraft sound is not HIFI,  only NOISE :(  )  -r
> 8000 -b 8
>
> Doing this,  i have been able to save a lot of live recorded music done
> with an old  digital recorder.
>
> I hope, it should do for you
>
>
> Cheers
>
> BTW: you will notice that Audacity  is very accurate since you can improve
> the sound with it, with the filters and effects tools.

ouups an error you must read :
sox -S  yoursoundorigin.vaw   -b 24 -r 48000  yoursoundconverted.vaw
-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] plib/svn recommended

[gerard robin]

On jeudi 29 janvier 2009, Melchior FRANZ wrote:
> In the last time I've submitted several fixes to plib, all of
> which are now committed. It is now recommended to use plib/svn
> (HEAD). Here's a list of the most important changes:
>
> - fix calculation of the slider handle size in 
>   widgets (as used in the nasal-console, the joystick info,
>   chat history, weather scenario)
>
> - autohide not used sliders (especially useful for the nasal
>   console)
>
> - scroll a  automatically if lines where added and
>   the slider handle is in the bottom position (especially
>   useful for the chat history)
>
> - make sliders in ,  conform with the behavior
>   of "modern" GUIs, that is: you can grab the handle anywhere
>   and drag; if you click on the slider background, then it
>   jumps one page. The old behavior was to immediately jump
>   to the clicked upon position, and had the disadvantage
>   the the slider didn't move *at all* before one reached
>   the handle's reference point in the center.
>
> It's also recommended to set the plib version number to
> 1.8.6 in ./src/util/ul.h:157 (PLIB_TINY_VERSION from 5 to 6),
> so that dialog.cxx can use a few of the new features. Some of
> the dialog XML files were already adapted for PLIB 1.8.6, and
> will work better with it. They will, however, work with 1.8.5
> as well. (Just worse. ;-)
>
>
> These contributions don't meant that the idea to suck up
> the remaining parts of PLIB into our repository has died.
>
> Occasionally, someone asks if/when we will migrate our GUI
> from PLIB to osgWidget. This is still planned, but at the
> moment it isn't an option. osgWidget offers only *very*
> simple GUI elements, basically just clickable colored
> rectangles and an input box. There's nothing like a listbox,
> multiline-textedit field. Everything is plain, without
> any 3D look. Also, osgWidget is still under heavy development,
> or was, as the lead developer just took some time off.
>
> m.
How do we get the plib/svn which is the link, ?
Within Plib official page
 http://plib.sourceforge.net/download.html 
there is nothing about svn

thanks


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] plib/svn recommended

[gerard robin]

On mercredi 11 février 2009, Ron Jensen wrote:
> On Wed, 2009-02-11 at 02:47 +0100, gerard robin wrote:
> > How do we get the plib/svn which is the link, ?
> > Within Plib official page
> >  http://plib.sourceforge.net/download.html
> > there is nothing about svn
> >
> > thanks
>
> http://sourceforge.net/svn/?group_id=382
> http://plib.svn.sourceforge.net/viewvc/plib/
>
>
Thanks, 
I have never used such SVN
Then my question which folder must used ?  branches ? tags ? trunk ?
I guess that i wont get the same result.

I noticed a remark  from Daan on that mailing list " What we can do as 
developers is making the user experience as gentle as possible" 
That is exactly the problem here,  GRRR


Cheers

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] plib/svn recommended

[gerard robin]

On mercredi 11 février 2009, Melchior FRANZ wrote:
> * gerard robin -- Wednesday 11 February 2009:
> > Then my question which folder must used ?  branches ? tags ? trunk ?
>
>   $ svn co https://plib.svn.sourceforge.net/svnroot/plib/trunk plib
>
> tags and branches in svn are the same as in CVS (just a lot more
> painful). And trunk is what HEAD is in CVS.
>
> > " What we can do as developers is making the user experience as
> > gentle as possible" That is exactly the problem here,  GRRR
>
> Except that this has nothing to do with users. You want to check
> out the *development* version of a library, because you want to
> *compile* it yourself, because that's what is recommended for
> *building* the *development* version of fgfs (for which you
> *develop* aircraft). Do you notice a pattern here? No user stuff
> involved here! We developers can handle that, don't we?  :-)
>
> m.
>
I disagree, since there is a mixing of supposed to be developer 'developing' 
and user 'using'.
For instance when i came back i noticed that the stable FG1.9.1 was delivered 
working with a not stable OSG library which an SVN version, in spite of an 
announced  coming stable OSG Version.

So i conclude that,  HERE within the FG developers mind , any user is 
considered  being  aware with development process.
Sure my question could have been asked on the user mailing list.
Which wont have changed nothing  :( .

BTW: developing model does not mean, developing programs.
My very old experience  has vanished , and it is not now with my 66 years old, 
that will start a carrier of developper .

Regards


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] plib/svn recommended

[gerard robin]

On mercredi 11 février 2009, Melchior FRANZ wrote:
> * gerard robin -- Wednesday 11 February 2009:
> > I disagree, since there is a mixing of supposed to be developer
> > 'developing' and user 'using'.
>
> Sure, every developer is also a user. You are certainly a FlightGear
> developer. But that's not what I meant.
>
> Users download a compiled release version from their distributor
> or from flightgear.org. They unpack the archive and run it. That
> may not always work perfectly, but generally it's not too hard.
>
> As soon as you check out source code and compile yourself, you
> enter the developer domain, no matter if you are (or consider
> yourself) a developer. And this will probably never be really
> easy. Developers want powerful tools, and those are usually more
> complicated to handle than user stuff. Maybe it's also because
> developers just *want* it difficult.  ;-)
>
> > Sure my question could have been asked on the user mailing list.
>
> No, no. There was nothing wrong with the question. Everybody
> *has* to get the info from somewhere.
>
> > My very old experience  has vanished , and it is not now with
> > my 66 years old, that will start a carrier of developper .
>
> Don't worry. There are younger folks doing a lot worse.   :-)

Oh, n,i don't worry, 
I am glad about it, since my choice of way of life is to have pleasure  with 
the real life.
When i started on  computer ( most of the guys, here,  where not born :) )  my 
target was to leave as soon as possible that ugly technical environment.
I got it,  :)  being mainly a representative user talking with developper.

To me,  modeling Aircraft is not development , only Drawing ( which is easy 
with these modern tools) and, only using an existing  FDM program ,  
according to the know how about aerodynamic and aircraft behaviour.
>
> m.
>
>

So, everything i can say, here,  is coming from a user mind  not a developer 
mind.

Regards


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] bad FG_ROOT/--fg-root

[gerard robin]

Wy i do have that stupid message ?


***
***
*** Warning: changing bad FG_ROOT/--fg-root 
to '/usr/local/share/FlightGear/data'
***
***
I never had it before ( from the prehistoric FG ages) 

Last fgfs cvs last stable osg (2.8)  and plib svn
-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] bad FG_ROOT/--fg-root

[gerard robin]

On jeudi 12 février 2009, Ron Jensen wrote:
> On Thu, 2009-02-12 at 19:05 +0100, gerard robin wrote:
> > Wy i do have that stupid message ?
> >
> >
> > ***
> > ***
> > *** Warning: changing bad FG_ROOT/--fg-root
> > to '/usr/local/share/FlightGear/data'
> > ***
> > ***
> > I never had it before ( from the prehistoric FG ages)
> >
> > Last fgfs cvs last stable osg (2.8)  and plib svn
>
> Because your FG_ROOT or --fg-root is set to the parent of your data
> directory /usr/local/share/FlightGear instead of your data
> directory /usr/local/share/FlightGear/data
>
Yes it is , it has ever been at that place.

So i don't understand why that message.
I never had it before.
 Any modification  within FG ?


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] /consumables/fuel/tank[0]/level-lb??? s

[gerard robin]

I don't understand this :
/tank[0]/level-lb  seems to be replaced by /tank[0]/level-lbs

What is the matter ?
Since the properties which are  declared within  the FDM ( JSBSim)   become 
wrong.

thanks

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] /consumables/fuel/tank[0]/level-lb??? s

[gerard robin]

On jeudi 12 février 2009, Anders Gidenstam wrote:
> On Thu, 12 Feb 2009, gerard robin wrote:
> > I don't understand this :
> > /tank[0]/level-lb  seems to be replaced by /tank[0]/level-lbs
>
> Hi,
>
> Yes, since we use -lbs everywhere else (in JSBSim too) and this lone
> level-lb property casued an annoying discrepancy with the same (level-lbs)
> property as provided by YASim.
>
> > What is the matter ?
> > Since the properties which are  declared within  the FDM ( JSBSim)  
> > become wrong.
>
> AFAICS Stuart did his best to track down and update all uses of level-lb
> in CVS. The properties /consumables/fuel/tank[x]/level-lb never existed
> at all in JSBSim/standalone so FDM configs that work(ed) in
> JSBSim/standalone should not be affected by this change.
>
> Another property naming heads up: JSBSim aircraft that use
> /engines/engine[x]/mp-osi do in fact use values in inHg and could
> preferably switch to the more properly named property
> /engines/engine[x]/mp-inhg .
>
> Cheers,
>
> Anders

OK, this make a mistmatch with my refueling system.

I will convert it to the properties which are within JSBsim itself, since the 
same property is there /fdm/jsbsim/propulsion/tank/contents-lbs 
And avoid to use the FG properties it is less risky   :)
Like avoiding to use Nasal when possible.   :)  :)  



-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] bad FG_ROOT/--fg-root

[gerard robin]

On jeudi 12 février 2009, gerard robin wrote:
> On jeudi 12 février 2009, Ron Jensen wrote:
> > On Thu, 2009-02-12 at 19:05 +0100, gerard robin wrote:
> > > Wy i do have that stupid message ?
> > >
> > >
> > > ***
> > > ***
> > > *** Warning: changing bad FG_ROOT/--fg-root
> > > to '/usr/local/share/FlightGear/data'
> > > ***
> > > ***
> > > I never had it before ( from the prehistoric FG ages)
> > >
> > > Last fgfs cvs last stable osg (2.8)  and plib svn
> >
> > Because your FG_ROOT or --fg-root is set to the parent of your data
> > directory /usr/local/share/FlightGear instead of your data
> > directory /usr/local/share/FlightGear/data
>
> Yes it is , it has ever been at that place.
>
> So i don't understand why that message.
> I never had it before.
>  Any modification  within FG ?

Again,

That recent FG version seems to be unable to find   'data'   which could 
explain the message.

My usual hierarchy is :

/usr/local/share/FlightGear/data   and so on.

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] /consumables/fuel/tank[0]/level-lb??? s

[gerard robin]

On jeudi 12 février 2009, Anders Gidenstam wrote:
> On Thu, 12 Feb 2009, Anders Gidenstam wrote:
> > AFAICS Stuart did his best to track down and update all uses of level-lb
> > in CVS.
>
> Oups, it was Syd who did this work. Sorry for the confusion.
>
> Cheers,
>
> Anders

No problem,   :)

In anycase when one don't know an aircraft it is ever difficult for him to 
update  the model.

I guess that   it is better to ask to the original author to do the update, 
when necessary.

Cheers


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] /consumables/fuel/tank[0]/level-lb??? s

[gerard robin]

On jeudi 12 février 2009, syd adams wrote:
> No problem,   :)
>
> In anycase when one don't know an aircraft it is ever difficult for him to
> update  the model.
>
> I guess that   it is better to ask to the original author to do the update,
> when necessary.
>
> Cheers
>
>
> --
> Gérard
> http://pagesperso-orange.fr/GRTux/
>
> This was discussed here on the mailing list just last week , and since I
> requested the change ,
> I figured it was my obligation to do the changes 
> I did say "(If the other aircraft modellers have no objection) " :)
> Cheers

I am not full time in front of my computer, then i could not answer NO  :)
Don't worry i have solved it in a different way. 

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] wildfire ?

[gerard robin]

Hello , 

I noticed about wildfire
the default within the preference file  is 
true
true

Won't it be better to have it default "false" ?
I did not find any box within menu to modify it like we have with cloud , 
light and so on.
For some reason,  if we don't want it ( look like a game   :(  ) will it be 
necessary to add some properties within the model itself ?

Thanks

BTW: to me, with my eyes deficiency,   it is the worth  i have ever seen,   i 
will need to get sun glasses 


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] wildfire ?

[gerard robin]

On samedi 14 février 2009, Melchior FRANZ wrote:
> * gerard robin -- Saturday 14 February 2009:
> > Won't it be better to have it default "false" ?
>
> Yes.
>
> > I did not find any box within menu to modify it like we have
> > with cloud ,  light and so on.
>
> Menu->Environment->Wildfire Settings
>
> > For some reason,  if we don't want it ( look like a game   :(  )
> > will it be necessary to add some properties within the model itself ?
>
> Don't crash your aircraft like a gamer, and you'll never see it!  :-P

Sure that is usual with MSFS Games, anyhow in the aircraft Company i don't 
remember  simulators with such wildfire ( when the student pilot crash ) .
Has it changed ?.

Who said, here,  that FG is NOT a GAME  ?  :)  :)  :) 
>
> m.
>


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] CVS: data/Aircraft/F-8E-Crusader Crusader-SetBase.xml, 1.23, 1.24

[gerard robin]

On samedi 14 février 2009, Melchior FRANZ wrote:
> * Gerard Robin -- Saturday 14 February 2009:
> > Log Message:
> > withdraw the "game coat"
> >
> > + 
> > + 
> > + false
> > + 
> > + 
>
> AIRCRAFT MUST *NOT* CHANGE SYSTEM SETTING!
>
> This setting disqualifies the F8 for inclusion in a release.
> Oh, well. Why do I always have to complain?! Maybe everyone
> else doesn't care about cleanliness and a sane concept,
> anyway. Sigh ...
>
> m.

And what about some specific aircraft feature regarding the crash processing.

In that case why don't you prohibit anything like, wake effect with the 
Catalina, jet blaster with turbine and so one.

I disagree with you and anybody here about it.

That is specific to the model

You should have discussed it here before implementing that feature.




-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] CVS: data/Aircraft/F-8E-Crusader Crusader-SetBase.xml, 1.23, 1.24

[gerard robin]

On samedi 14 février 2009, gerard robin wrote:
> On samedi 14 février 2009, Melchior FRANZ wrote:
> > * Gerard Robin -- Saturday 14 February 2009:
> > > Log Message:
> > > withdraw the "game coat"
> > >
> > > + 
> > > + 
> > > + false
> > > + 
> > > + 
> >
> > AIRCRAFT MUST *NOT* CHANGE SYSTEM SETTING!
> >
> > This setting disqualifies the F8 for inclusion in a release.
> > Oh, well. Why do I always have to complain?! Maybe everyone
> > else doesn't care about cleanliness and a sane concept,
> > anyway. Sigh ...
> >
> > m.
>
> And what about some specific aircraft feature regarding the crash
> processing.
>
> In that case why don't you prohibit anything like, wake effect with the
> Catalina, jet blaster with turbine and so one.
>
> I disagree with you and anybody here about it.
>
> That is specific to the model
>
> You should have discussed it here before implementing that feature.

To conclude,  it is not an environment feature or scenery feature , it is only 
a model feature.

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] CVS: data/Aircraft/F-8E-Crusader Crusader-SetBase.xml, 1.23, 1.24

[gerard robin]

On samedi 14 février 2009, Melchior FRANZ wrote:
> * Gerard Robin -- Saturday 14 February 2009:
> > Log Message:
> > withdraw the "game coat"
> >
> > + 
> > + 
> > + false
> > + 
> > + 
>
> AIRCRAFT MUST *NOT* CHANGE SYSTEM SETTING!
>
> This setting disqualifies the F8 for inclusion in a release.
> Oh, well. Why do I always have to complain?! Maybe everyone
> else doesn't care about cleanliness and a sane concept,
> anyway. Sigh ...
>
> m.

And what about some specific aircraft feature regarding the crash processing.

In that case why don't you prohibit anything like, wake effect with the 
Catalina, jet blaster with turbine and so one.

I disagree with you and anybody here about it.

That is specific to the model

You should have discussed it here before implementing that feature.




-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] CVS: data/Aircraft/F-8E-Crusa der Crusader-SetBase.xml , 1.23, 1.24

[gerard robin]

On dimanche 15 février 2009, Ron Jensen wrote:
> On Sat, 2009-02-14 at 23:56 +0100, gerard robin wrote:
> > On samedi 14 février 2009, gerard robin wrote:
> > > On samedi 14 février 2009, Melchior FRANZ wrote:
> > > > * Gerard Robin -- Saturday 14 February 2009:
> > > > > Log Message:
> > > > > withdraw the "game coat"
> > > > >
> > > > > + 
> > > > > + 
> > > > > + false
> > > > > + 
> > > > > + 
> > > >
> > > > AIRCRAFT MUST *NOT* CHANGE SYSTEM SETTING!
> > > >
> > > > This setting disqualifies the F8 for inclusion in a release.
> > > > Oh, well. Why do I always have to complain?! Maybe everyone
> > > > else doesn't care about cleanliness and a sane concept,
> > > > anyway. Sigh ...
> > > >
> > > > m.
> > >
> > > And what about some specific aircraft feature regarding the crash
> > > processing.
> > >
> > > In that case why don't you prohibit anything like, wake effect with the
> > > Catalina, jet blaster with turbine and so one.
> > >
> > > I disagree with you and anybody here about it.
> > >
> > > That is specific to the model
> > >
> > > You should have discussed it here before implementing that feature.
> >
> > To conclude,  it is not an environment feature or scenery feature , it is
> > only a model feature.
>
> Gerard,
>
>  Respectfully I must disagree with you here.  This is a system feature
> and should not be adjusted in random aircraft -set files.  It is
> properly set in preferences.xml and autosave.xml, not each aircraft -set
> file.  This property also autosaves, so setting it here silently
> disables it globally and permanently for any user who runs the F-8E.
>
> Regards,
> Ron
That exactly what i want, since i do have some crash processing done and 
coming for every models that i am working on.
It will become ridiculous that an aircraft sinking ( for instance) will burn 
suddenly.

NO NO 

That is part of a model.

Can you imagine a Catalina gently crashing on water ( when landing)  gerring 
Wildfire ?



-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] CVS: data/Aircraft/F-8E-Crusa der Crusader-SetBase.xml , 1.23, 1.24

[gerard robin]

On dimanche 15 février 2009, gerard robin wrote:
> On dimanche 15 février 2009, Ron Jensen wrote:
> > On Sat, 2009-02-14 at 23:56 +0100, gerard robin wrote:
> > > On samedi 14 février 2009, gerard robin wrote:
> > > > On samedi 14 février 2009, Melchior FRANZ wrote:
> > > > > * Gerard Robin -- Saturday 14 February 2009:
> > > > > > Log Message:
> > > > > > withdraw the "game coat"
> > > > > >
> > > > > > + 
> > > > > > + 
> > > > > > +  > > > > > >false + 
> > > > > > + 
> > > > >
> > > > > AIRCRAFT MUST *NOT* CHANGE SYSTEM SETTING!
> > > > >
> > > > > This setting disqualifies the F8 for inclusion in a release.
> > > > > Oh, well. Why do I always have to complain?! Maybe everyone
> > > > > else doesn't care about cleanliness and a sane concept,
> > > > > anyway. Sigh ...
> > > > >
> > > > > m.
> > > >
> > > > And what about some specific aircraft feature regarding the crash
> > > > processing.
> > > >
> > > > In that case why don't you prohibit anything like, wake effect with
> > > > the Catalina, jet blaster with turbine and so one.
> > > >
> > > > I disagree with you and anybody here about it.
> > > >
> > > > That is specific to the model
> > > >
> > > > You should have discussed it here before implementing that feature.
> > >
> > > To conclude,  it is not an environment feature or scenery feature , it
> > > is only a model feature.
> >
> > Gerard,
> >
> >  Respectfully I must disagree with you here.  This is a system feature
> > and should not be adjusted in random aircraft -set files.  It is
> > properly set in preferences.xml and autosave.xml, not each aircraft -set
> > file.  This property also autosaves, so setting it here silently
> > disables it globally and permanently for any user who runs the F-8E.
> >
> > Regards,
> > Ron
>
> That exactly what i want, since i do have some crash processing done and
> coming for every models that i am working on.
> It will become ridiculous that an aircraft sinking ( for instance) will
> burn suddenly.
>
> NO NO
>
> That is part of a model.
>
> Can you imagine a Catalina gently crashing on water ( when landing) 
> gerring Wildfire ?

And maybe
 To be more precise.

Yes, a system must not be adjusted within the model itself.

No,  that feature must not be a system feature.
Only a tool (in that case an effect) which could be included in a model if the 
creator wants it.





-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] CVS: data/Aircraft/F-8E-Crusader Crusader-SetBase.xml , 1.23, 1.24

[gerard robin]

On dimanche 15 février 2009, Laurent wrote:
> IMHO, in that case this is a bug about when wildfire should be
> started. If the plane is actually missing a landing on water, it
> should be detected by the main program as it, not as a land crash. A
> catalina crashing on land should create fire. Deactivate wildfire for
> the whole environment is not the best solution.
>
> Laurent
>

On land crash maybe yes,  maybe no. :) rather no 

I could reproduce a specific case with the war version which had torpedo.
A day, i will make that version, and then i could simulate an explosion with 
wildfire, a Zero shooting it

We only need a shoot 'em up feature :)   :)  :)  :)

The next FG step development  ???  :)

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] CVS: data/Aircraft/F-8E-Crusader Crusader-SetBase.xml , 1.23, 1.24

[gerard robin]

On dimanche 15 février 2009, Detlef Faber wrote:
> Am Sonntag, den 15.02.2009, 09:45 +0100 schrieb Detlef Faber:
> > Am Samstag, den 14.02.2009, 23:15 +0100 schrieb gerard robin:
> > > On samedi 14 février 2009, Melchior FRANZ wrote:
> > > > * Gerard Robin -- Saturday 14 February 2009:
> > > > > Log Message:
> > > > > withdraw the "game coat"
> > > > >
> > > > > + 
> > > > > + 
> > > > > + false
> > > > > + 
> > > > > + 
> > > >
> > > > AIRCRAFT MUST *NOT* CHANGE SYSTEM SETTING!
> > > >
> > > > This setting disqualifies the F8 for inclusion in a release.
> > > > Oh, well. Why do I always have to complain?! Maybe everyone
> > > > else doesn't care about cleanliness and a sane concept,
> > > > anyway. Sigh ...
> > > >
> > > > m.
> > >
> > > And what about some specific aircraft feature regarding the crash
> > > processing.
> >
> > Than it would of course be acceptable, but the Crusader doesn't show any
> > specific behaviour.
>
> ... at least on land, on water it doesn't burn, and still doesn't burn if
> one manages to slide onto the shore. The Water Reactions are unaffected by
> the wildfire feature.
>
> > > In that case why don't you prohibit anything like, wake effect with the
> > > Catalina, jet blaster with turbine and so one.
> > >
> > >
> > >
> > > I disagree with you and anybody here about it.
> > >
> > > That is specific to the model
> > >
> > > You should have discussed it here before implementing that feature.
> >
> > The wildfire feature has been around some time now and as far as I know,
> > nobody has complained. It can be turned off by the user and I'm sure a
> > lot of users (like me) like it.
> >
> > If you wish a discussion, post to the list and don't hinder the users of
> > your Aircraft to use a feature FlightGear offers.

You know better than i, what  i intend to do with the Crusader model and any 
others that i am working on , regarding the crash management.
Congratulation.

In addition to it, with some others models, like glider crashing,  will you  
conclude that the wildfire suit to it ?  
But, if it is a terrorist wearing a bomb.


Cheers

BTW: i hope that my English is understandable for you.

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] CVS: data/Aircraft/F-8E-Crusader Crusader-SetBase.xml , 1.23, 1.24

[gerard robin]

On dimanche 15 février 2009, Arnt Karlsen wrote:
> On Sat, 14 Feb 2009 23:36:30 + (GMT), Stuart wrote in message
>

>
> ..then you have exotic compromises like crashing on ice, dead stick
> landings in methane clouds downwind of broken pipelines, ripe full
> hydrazine tanks as you ditch in freezing water... messy. ;o)
>
> ..needs at least FG-wide and per-model settings.
>

> ..maybe... a fire requires an oxidizer, e.g. air, oxygen,
> clorine etc, a fuel hot enough to support the initial fire
> beyond the ignition, and an ignition source, e.g. exhaust
> gas heat, hot engine parts or the shining Sun.


Among he conditions to get fire is,
 first ,  is there anything to burn ?
 second is there any ignition source ?
That is answer of a friend fireman.

A F-8E with empty tank, when the pilot try to land on the ground on a  flat 
area, which will be detected by FG like a crash , there won't be flame or 
explosion immediately or never , only, mainly dust .

A F-4U7 missing the catapulting  from a Carrier, won't get fire, only sinking 
The same one missing the landing on carrier , won't immediately get fire..., 
and sometime never.

And so on.

We could talk longer and longer about it , however, to me, talking and 
talking,  is out of our  main goal, which is 
 to make the best FDM first, and
 then when possible the better eye candy we can   ( i mean visual reality ).

I was STUPID since, i  thought that the modelers were free to create the 
Aircraft in order to answer to these old criteria ( best FDM, eye candy).
I noticed now that we are dependent of some constraints, we must accept 
anything coming from the mind of DEVELOPPER who decide for us , what is good 
or wrong for a model.
I did accept these constraints until now,  since i took it being an 
improvement for the models, and to me there is a lot of stuff to be done.
I do not accept that  "fire"  feature  since it is not realistic  for a lot of 
models.
Because the model itself will never get fire under these conditions , or 
because the process is wrong according to the situation of the crash.


==> I don't mind to be that category DISQUALIFIED ( Melchior ), since my life 
is not fed with FG  :)  . I hope nothing with it,  but the pleasure to be 
with  friends.
You probably never noticed it but , it is some time ago that i am 
DISQUALIFIED, since i had removed the Redout generic one being replaced by a 
specific one included in the FDM itself.


==> I have been reproached (Detlef) my late reaction, regarding that topic.
I know that there is a lot of developers and models creators here who spend 
day and night on the computer  7 day per weeks 12 months per year, i can 
understand,  that the reaction would be realtime like.

==>I am not from  that homo-sapiens category, i can have some long period AFK, 
being elsewhere ( hospital, vacancies, family, hobbies or getting 
some rest since i can't stay several hours looking at a screen)
Fortunately ( since 1968) i have never  been shooted with computing (to me,  
it is only a tool ).

To CONCLUDE, about the  Wildfire feature itself, the idea was GOOD, the way to 
use it, is WRONG.

If we had it,  like an optional feature on the model itself offerd to the 
model creator, he would be free to use it  or not according some predefined 
conditions ( i do not reject it, since i have specific situations were i 
could use it).

ANY animation which is model dependant must be triggered by the model itself, 
ONLY the model.

The Pilot/User must not decide if i wants to get fire when crashing.
That User must have the choice to see  or not these specifics models 
animations which are GPU consummers, according to their equipments ( for 
instance my old computer  freeze - 1 fps  on KSFO with the the osg 
animations) 


BTW: i just read the Sebastien mails, i do like his proposal, which open the 
choice according to a predefined   model crash scenario

Cheers


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] CVS: data/Aircraft/F-8E-Crusader Crusader-SetBase.xml , 1.23, 1.24

[gerard robin]

On dimanche 15 février 2009, Nicolas Quijano wrote:
> Gerard, you're not getting it : if I want wildfire to spread when I crash a
> Crusader, you shouldn't have a say in it, period.
> Let me try to explain it from the user's perspective : a user of both the
> dev's creation, the simulation, and in this case, your a/c.
>
> I'm the one piloting the Crusader, and running Flight Gear on my machine.
> I do no want you or anyone else to make a sneaky change to a global pref,
> be it wildfire or anything else.
> If I don't want wildfire, I'll turn it off in the global prefs (and
> incidentally, if anyone is counting, it's off ;))
>
> It simply makes no sense for you to change my global prefs in one a/c : how
> do you know my next session is not wildfire training ? Or that I'm not
> going to be filming  a bunch of firefighters in the simulation ?
>
> What's next ? Saving and archiving failures in a an a/c with system wide
> effects ?
> If I understand this correctly, that means the next time I start the sim,
> the fire is off, without any means for me to know so unless I had read
> about this here : I'm not your typical user, in that I'm also a
> professional software developer and I'm used to fighting with my computer
> to get things done, whatever platform I'm using atm.
> So I'd look for a solution...
>
> Imagine how "hiding" a global prefs like that in a a/c FDM config files is
> going to make it hard for the average user to know what the hell is going
> on with his sim : Flight Gear is already very complex, no need to go out of
> our way to make it hard for people to use it.
>
> I really don't care for the wildfire feature at this time, because it
> doesn't align with my current interests, and I have a problem with
> uncontrolled eye candy (the game dev with 5 shipped and 10+ cancelled
> projects talks here), but that's another story, and it has more to do with
> uncontrolled triangle and texture usage...
> But that is one of the great things with FGFS : you can still run in MP
> while flying in  your own instance of the world, with its own particular
> config.
> It's important to realize that making that kind of change within the a/c
> has farther ranging effects than you seem to realize.
>
> First impressions are often the only impression (don't I know it ;)), and
> this doesn't help a new user to truly gauge the possibilities of the
> program if there are plenty of little sneaky settings like that.
> It makes FGFS look messy to the outsider, and consumed by petty bickering.
>
> If it's a problem of language, I'll be happy to write this in my native
> French :)
>
> Cheers, and keep working on the beautiful Crusader,
> Nic

Thanks for your mail,  i have just sent to you a French private mail.

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Groundcache overhaul

[gerard robin]

On dimanche 01 mars 2009, Mathias Fröhlich wrote:
> Fred,
>
> On Sunday 01 March 2009 18:40:20 Frederic Bouvier wrote:
> > I see a huge memory consumption when trying to start from EGLL ( or
> > EDDF, or EHAM, or LFPO ) with the scenery available via TerraSync/SVN.
> > The process memory climbs to its maximum ( 2Gb for a 32 bits system -
> > WinXP ) and the fgfs.exe process dies. This phenomenon doesn't occur at
> > KSFO. The problem was not there yesterday morning.
>
> Ok, I have tracked that down to a object sharing problem for the bounding
> volume trees that does not work as I thought it works.
> ... well I did the original code two years ago that is responsible for that
> - but I did not remember correct :-/
>
> The problem is well solvable but not today.
> I have checked in a crude workaround that brings my memory consumption at
> LFPO back to about 10% more than before - which should be acceptable for
> now. If you still have unsolvable problems let me know.
> I will work on a good solution this week.
>
> Anyway, that svn scenery looks really nice! I did not know that too god
> before!
>
> Greetings
>
> Mathias

Congratulation to Mathias, landing on a ship full speed (25 knots) with an 
helicoptere piloted by a bad pilot (me) is now possible,
Here the whitness (snapshot).
No slide on it. It touched the desk  exactly at that place ( out of the H 
Circle center )
 http://pagesperso-orange.fr/GRTux/Ouf.jpg
Thanks

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Nasal alternatives : possible, of course,

[gerard robin]

On jeudi 05 mars 2009, Detlef Faber wrote:
> Ncolas,
>
> I didn't want to comment on your first post, everyone has a bad day
> sometimes, but here I like to add my 2 ct anyway.
>

> I'm a simple content contributor with very little background in
> programming. When I made my first Aircraft (the bf109) I was confronted
> with the need to deploy slats automatically at a given speed. I din't
> want to embed C++ code or had such a complex script that the error
> messages in FG wouldn't help me and I previously only used a bit of
> python. I looked at some Nasal scripts and within a few hours it worked.
>
> I was impressed how easy it is to write even complex Nasal scripts.
> Later I started developing the walker feature that made it possible to
> walk around in the scenery, all with nasal. Stuart kindly enhanced the
> walker and added an animation system to it (see bluebird), again with
> nasal.
>
> Others have made Flight computers with it (see V-22 and Su-37). Nasal is
> a worthy tool and you gave no proof that Lua can do the same.
>
> Given the fact that FG is platform independant I don't know if the
> embedded C++ is doing the same on Windows, Linux, PPC and intel Macs.
> ( apart from the fact that if I was able to code c++ I would embed it to
> FG rather than in an Aircraft specific script).
>
> A lack of documentation may be the case, but on this list are a lot of
> friendly people helping out.
>
> Maybe there hasn't been a lot of praise for nasal, but I guess the broad
> use of nasal, even among JSBSim developers speaks for itself.

However, with JSBSim,  Nasal or any other script Langage could be mostly 
avoided.
No problem to get an automatic flap, or to get an automatic taxying.
Any JSBsim  FDM model makers knows it.
That Script Langage  is becoming necessary when we want to use with some 
generic features ( instruments, radars ) which are developed and 
offered with the base package.
  
> As far as 
> I know there hasn't been any comments of lacking nasal features (that
> weren't added within a short time).
>
> Finally: I _like_ Nasal!
>
> > Cheers,
> > Nic
> >
> > --
> > Be Kind.
> > Remember, everyone is fighting a hard battle.

>
> Greetings



-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Reproducible crash in mk_viii.cxx

[gerard robin]

On lundi 09 mars 2009, Durk Talsma wrote:
> Hi Geoff,
>
> On Sunday 08 March 2009 20:56:52 Geoff McLane wrote:
> > Yep!
> >
> > Tried ...
> > --aircraft=CitationX --airport=CYOW --runway=25 --fg-scenery=
> > $HOME/Scenery-1.0.1
>
> Thanks for you report. Good to know, I'm not the only one, at that adds to
> the robustness of the crash. I think it's too early to draw any firm
> conclusions, but my impression is that it's more than just the code on
> mk_viii that is blowing. The only thing I tentatively conclude is that at
> this location something is going terribly wrong in updating FlightGear's
> position, as judged by:
>
> - The position string sent to terrasync
> - Local time being NaN (zapping to a non-existent time zone?)
> - A host of Culling errors. (position so far away that depth becomes NaN)?
>
> Next step is to check whether other aircraft produce the same crash, and
> whether the FDM (i.e. non-yasim) aircraft produce the same problem.

Yes with JSBSim there is the same "NAN" error , more or les randomly.
Difficult to catch a specific cause.
>
> Cheers,
> Durk



-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Nasal alternatives : possible , of course, but trivial or hair pulling tas k ?

[gerard robin]

On dimanche 08 mars 2009, Melchior FRANZ wrote:
> * Nicolas Quijano -- Sunday 08 March 2009:
> > As for "secret sources", they'll name themselves if they feel
> > like it,
>
> That would be fun! But I won't hold my breath.
>

I don't know if i am part of that  "secret sources", anyhow , in my case, 
avoiding to use a  Nasal script when that is not necessary , won't lead to 
the conclusion that we don't like Nasal, but more or less we ignore it  :)
I said it before most of the features animation, electrical, hydraulical,  
autopilot, .. etc, which are necessary when making a model with JSBsim 
can be done without Nasal.
I have kept some old Archives of FG were the keyboard definition is mostly 
xml, the main features are still working. Then my personal configuration only 
use the minimum of Nasal with it.

I concluded that the question is not to to use Nasal , LUA or any other script 
language, the question to me, is the larger we have the choice of  tools and 
the freedom ( no stupid dictat ) to use  or not according to our personal 
configuration, the better will be the system.

Regards



-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Nasal alternatives : possible , of course, but trivial or hair pulling tas k ?

[gerard robin]

On lundi 09 mars 2009, gerard robin wrote:
> On dimanche 08 mars 2009, Melchior FRANZ wrote:
> > * Nicolas Quijano -- Sunday 08 March 2009:
> > > As for "secret sources", they'll name themselves if they feel
> > > like it,
> >
> > That would be fun! But I won't hold my breath.
>
> I don't know if i am part of that  "secret sources", anyhow , in my case,
> avoiding to use a  Nasal script when that is not necessary , won't lead to
> the conclusion that we don't like Nasal, but more or less we ignore it  :)
> I said it before most of the features animation, electrical, hydraulical,
> autopilot, .. etc, which are necessary when making a model with JSBsim
> can be done without Nasal.
> I have kept some old Archives of FG were the keyboard definition is mostly
> xml, the main features are still working. Then my personal configuration
> only use the minimum of Nasal with it.
>
> I concluded that the question is not to to use Nasal , LUA or any other
> script language, the question to me, is the larger we have the choice of 
> tools and the freedom ( no stupid dictat ) to use  or not according to our
> personal configuration, the better will be the system.
>
> Regards

With =>personal configuration<= , i mean, (since i made model) accordingly to 
the Model specifications,  which will involve the right tools to do it and to 
give to the user the right model according to these specifications


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Reproducible crash in mk_viii.cxx

[gerard robin]

On lundi 09 mars 2009, Durk Talsma wrote:
> Hi Gerard,
>
> On Monday 09 March 2009 12:06:58 gerard robin wrote:
> > Yes with JSBSim there is the same "NAN" error , more or les randomly.
> > Difficult to catch a specific cause.
>
> Do you mean that you can replicate the specific bug I reported, or that you
> experience random NAN errors?
>
> Cheers,
> Durk

Only random NAN errors.
To be more precise , when it comes up,  FG does not crash. 
Only getting  on the console the "NAN" messages infinitely,  with a sudden 
slow down of the FPS to  1 .
The only way to stop it, is to cancel FG.

I did not tried to replicate the specific bug.

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Saving Instant Replay to a File

[gerard robin]

On mardi 10 mars 2009, Stefan Seifert wrote:
> On Tuesday 10 March 2009 14:16:23 Matthew Barousse wrote:
> > Hey all,
> > I'm currently attempting to modify flight gear, so that I may save and
> > re-play flights, exactly like the instant replay feature, but with a save
> > file.
> >
> > My next task is to implement a save-to-file feature. I was thinking the
> > easiest path would be to write the instant replay memory buffers
> > (FGReplayData, replay_list_type) out to a file, and modify the replay
> > method to read that file, instead of straight from the memory.
> >
> > I'm just wondering if anyone can foresee any problems with what I'm
> > doing, or has any pointers or tips for me? I'm just getting started with
> > FG development, and it's a bit overwhelming.
>
> This sounds very interesting. I think the replay feature needs quite some
> love anyway. For example, its still a mix of replayed and current
> properties. One cannot really replay a landing on the carrier, because the
> carrier's position is not recorded but still updated, so it looks like
> one's landing in the air.

Which is the drama of my life   :)  , only a non moving carrier can gives a 
nice replay.
There is a lot of extra animations within the aircraft itself which are not 
reproduced.

>
> Stefan



-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Reproducible crash in mk_viii.cxx

[gerard robin]

On mercredi 11 mars 2009, syd adams wrote:
> Thanks , I was trying to figure out how to use gdb too :). I had a few
> errors here , maybe related .
> While testing the P47 , I took off from KSFO and headed towards the
> Nimitz.At about the coastline , altitude about 2000 ft every thing
> paused... I thought I accidentally hit "p" . Looking through the property
> tree I noticed sim/crashed was true.I haven't been able to reproduce this,
> though. Second problem I ran into last night was starting at any airport
> with the DC-6 , everything was fine until I started the engines ... then
> the screen went black , dropped to 1 fps , and a steady stream of:
>
> CullVisitor::apply(Geode&) detected NaN,
> depth=nan, center=(0.002885 0.0187575 -0.0095325),
> matrix={
> nan nan nan nan
> nan nan nan nan
> nan nan nan nan
> nan nan nan nan
> }
>
> I kind of suspect with the second problem that it might be a badly
> configured yasim file... I had the same problem long ago with gear
> values...
> The jsbsim version flew fine , no problems.
> I'll tweak it some more and see what happens.
> Cheers



With JSBSim aircrafts i get exactly the same problem/errors , it happens 
mainly when i do an airborn for long trip ( more than 1 hour) with autopilot.
I got that errors with several models not only a specific one.

To me, that is not new, it came up  6 or 7 month ago.




>
> On Tue, Mar 10, 2009 at 3:07 PM, Durk Talsma  wrote:
> >  On Tuesday 10 March 2009 22:52:47 Csaba Halász wrote:
> > > Recent gdb does, exactly as Geoff wrote, with --args.
> >
> > Ah, well, it's been approx since 1996 since I last read gdb
> > documentation...
> >
> > Cheers,
> >
> > Durk
> >
> >


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Reproducible crash in mk_viii.cxx

[gerard robin]

On mercredi 11 mars 2009, Jon S. Berndt wrote:
> > With JSBSim aircrafts i get exactly the same problem/errors , it
> > happens
> > mainly when i do an airborn for long trip ( more than 1 hour) with
> > autopilot.
> > I got that errors with several models not only a specific one.
> >
> > To me, that is not new, it came up  6 or 7 month ago.
> >
> > --
> > Gérard
> > http://pagesperso-orange.fr/GRTux/
>
> Which version of the code (JSBSim) are you using?
>
> Jon
>
>
>
Hello Jon,
That one, which is available  with FG CVS.
However i don't think it is FDM related ,  i would think that it is loading 
scenery  related , since i never got the problem when flying over the sea.

Cheers



-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] AIrcraft still refering to space-bar for starting

[gerard robin]

On mercredi 11 mars 2009, Stuart Buchanan wrote:
> Hi Guys,
>
> Having noticed that the Vulcan still refers to starting the engines using
> the space bar (whoops!), I did a quick grep of the .xml files in Aircraft,
> and found reference to "space" in the aircraft indicated below.
>
> If any aircraft maintainer would like me to correct their aircraft for
> them, please just let me know.
>
> Thanks,
>
> -Stuart
>
> ./an2/an2-set.xml
> ./Noratlas/Help/Nord-2502-help.xml
> ./Noratlas/Help/Nord-2501-help.xml
> ./OV10/OV10_USAFE-set.xml
> ./OV10/OV10_NASA-set.xml
> ./OV10/OV10_CDF-set.xml
> ./Hurricane/help.xml
> ./Spitfire/spitfire-help.xml
> ./Spitfire/spitfireIIa-set.xml
> ./Spitfire/help.xml
> ./Spitfire/seafireIIIc-set.xml
> ./ogel/ogel-set.xml
> ./P-38-Lightning/Help/P-38L-help.xml
> ./PBY-Catalina/Help/Catalina-help.xml
>
As far i remember. the model i had done  were reffering in the help .xml to 
both "s"   and "space" telling the user to choose according to the FG version  
that he was using.
Then nothing wrong
-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] nimitz elevators non solid

[gerard robin]

On jeudi 12 mars 2009, jean pellotier wrote:
> hi,
>
> I've got a problem with the elevators on nimitz, since some days, when
> called up, it looks ok, but elevator 3d model isn't solid, the part
> solid is where is the elevator down.
> each try i finish on the low position (in best case) under the elevator
> 3d model.
>
> jano
>
I got that problem with the French Carrier which had not triangulated surface.

I solved it with reformat the ac model from quad to triangulated  surface.

Anyhow,  now,  with the  Mathias improvements,   carriers do not longer  want  
 definitions.

Cheers


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] white horizontal line on screen

[gerard robin]

Hello,
I am getting   an horizontal  line on screen , that is not new, i had it 
before, (at least two months ago) .
The position of the line is dependent of the view angle,  bottom when looking 
to down, top when looking to up.

It is not graphic card dependent , since i get it on several GPU ( Nvidia 
cards) on several computers/configurations.

The FG parameters are 
geometry=1920x1440
bpp=32

here the snapshot 
http://pagesperso-orange.fr/GRTux/Line.jpg

Is it just me ?


Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] white horizontal line on screen

[gerard robin]

On dimanche 15 mars 2009, Melchior FRANZ wrote:
> * gerard robin -- Sunday 15 March 2009:
> > I am getting   an horizontal  line on screen , that is not new,
>
> Yes, that's where near-camera and far-camera meet (well, or *should*
> meet :-). It's a known problem, and was reported before. It should
> definitely not be in fgfs 2.0.
>
> m.
>
>
OK,  i remove the snapshot


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal tanker.nas, NONE, 1.1

[gerard robin]

If that is . right
 => allow aar-equipped aircraft to request a tanker everywhere without 
scenario <==

You should know that aircrafts which have some specific AAR won't be able to 
use it.
  

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal tanker.nas, NONE, 1.1

[gerard robin]

On dimanche 15 mars 2009, Melchior FRANZ wrote:
> * gerard robin -- Sunday 15 March 2009:
> > You should know that aircrafts which have some specific AAR won't
> > be able to use it.
>
> All that work(ed) with the tanker scenarios should also work with
> this. It doesn't do anything magic. Just offer a tanker and set
> the aircraft's "contact" flag if it's close enough.
>
> m.
>

I was not sure  because of this :

 =>  make sure /systems/refuel/ exists <=


Since  a specific AAR could use any other specific property




-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal tanker.nas, NONE, 1.1

[gerard robin]

On dimanche 15 mars 2009, Melchior FRANZ wrote:
> * gerard robin -- Sunday 15 March 2009:
> >  =>  make sure /systems/refuel/ exists <=
> >
> > Since  a specific AAR could use any other specific property
>
> This should have been "systems/refuel", without the leading
> slash. It's the tanker's property /ai/model/tanker[*]/refuel/contact.
> This is the one and only property that MP or AI tankers use(d) to
> indicate contact.
>
> You could just try if it works for you.
>
> m.
>
Then, if my understanding is right we don't need the /systems/refuel   
property.

ONLY  the  /ai/model/tanker[*]/refuel/contact  is significant.



-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [RFC] ac3d and materials

[gerard robin]

On lundi 16 mars 2009, Mathias Fröhlich wrote:
> Hi all,
>
> For ac models, we have currently a step in the scenery loading process that
> modifies the material settings to match the material settings of the old
> plib loader.
> In fact this just overwrites the material settings and throws away useful
> information that is in the ac file that is still there up to the point
> where we just destroy that information.
> I introduced that step at the time of the openscenegraph switch to make the
> transition easier.
>
> I would like to remove that step now and make use of the full material
> information contained in the ac file.
> I believe that this is a step into the right direction, but this *does*
> change the visual appearance of some of our models. So when this gets
> removed, I guess that some of the models material colours need to be
> adjusted in some way.
>
> Comments?
>
> Greetings
>
> Mathias
>

AND now, again,  working with poly ( face) not  triangulated.
Thanks for the work

Cheers


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel