John Wojnaroski writes:
>
>
>
> > John,
> >
> > Did you do a "cvs update -d" in the base directory?
> >
> Not exactly, but I did a download of the latest snapshot from rockfish and
> untarred the file to /usr/local/FlightGear
There were some changes today, so you may want to grab the next
snap
> John,
>
> Did you do a "cvs update -d" in the base directory?
>
Not exactly, but I did a download of the latest snapshot from rockfish and
untarred the file to /usr/local/FlightGear
John W.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http
> For what it's worth, most of the SimGear API is documented with
> doxygen.
>
> Curt.
I knew that - I took a look the other day and decided that Doxygen would
be satisfactory. :-)
Just downloaded it. I'll be trying it out.
Jon
smime.p7s
Description: application/pkcs7-signature
Jon Berndt writes:
> > Jon S Berndt writes:
> > >
> > > Does anyone have any experience with moving from Doc++ to
> > > Doxygen? I'm thinking of making the move. Doxygen seems to
> > > be what I had hoped Doc++ would become, but seems to have
> > > stalled. It looks like many of the identifiers a
Jon Berndt writes:
> > Jon S Berndt writes:
> > >
> > > Does anyone have any experience with moving from Doc++ to
> > > Doxygen? I'm thinking of making the move. Doxygen seems to
> > > be what I had hoped Doc++ would become, but seems to have
> > > stalled. It looks like many of the identifiers ar
> Jon S Berndt writes:
> >
> > Does anyone have any experience with moving from Doc++ to
> > Doxygen? I'm thinking of making the move. Doxygen seems to
> > be what I had hoped Doc++ would become, but seems to have
> > stalled. It looks like many of the identifiers are the
>
> Jon
>
> Doxygen start
The physics geek in me says:
That's tricky stuff. (Antennas are cool)
David Megginson wrote:
> Here's a good page for when we add navaid transmitters to the scenery
> (fairly soon):
>
> http://www.xuser.com/~daled/navaids/
>
> All the best,
>
> David
>
> --
> David Megginson, [EMAIL PROTECTED
FYI
http://www.ngs.noaa.gov/AERO/ASPphoto/aspphoto.html
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Hi,
I'm not sure if it's new or not but I think Nvidia is getting more and more
respect among Open Source comunity.
They are opening the Nvidia compiler.
The source code is available at:
developer.nvidia.com or www.cgshaders.org
--
Sergio Roth
Linux user#226380
SuSE 8.0
___
David Megginson writes:
> Norman Vine writes:
>
> > It used to be I could use the CVS browser and see
> > how things were before the 'grand rewrite' but the historical CVS seems
> > to have disappeared so now we are deprived of that 'work around' also
>
> We might still be able to talk Curt i
Norman Vine writes:
> FYI
>
> http://www.ngs.noaa.gov/AERO/ASPphoto/aspphoto.html
Very nice -- we can use these to add more taxiways and aprons.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flight
John,
Did you do a "cvs update -d" in the base directory?
Curt.
John Wojnaroski writes:
> Well, I was going to send Curtis the latest and greatest 3D cloud code.
>
> Did a fresh checkout and build of SimGear and FlightGear plus the base
> package before applying the changes and running a few
Here's a good page for when we add navaid transmitters to the scenery
(fairly soon):
http://www.xuser.com/~daled/navaids/
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EM
Well, I was going to send Curtis the latest and greatest 3D cloud code.
Did a fresh checkout and build of SimGear and FlightGear plus the base
package before applying the changes and running a few tests, but the program
is aborting when reading the command options line in "test" which is:
#!/bin/
Norman Vine writes:
> It used to be I could use the CVS browser and see
> how things were before the 'grand rewrite' but the historical CVS seems
> to have disappeared so now we are deprived of that 'work around' also
We might still be able to talk Curt into restoring the full archive.
All t
Jon S Berndt writes:
>
> Does anyone have any experience with moving from Doc++ to
> Doxygen? I'm thinking of making the move. Doxygen seems to
> be what I had hoped Doc++ would become, but seems to have
> stalled. It looks like many of the identifiers are the
Jon
Doxygen started life as Doc++ s
On Tue, 2002-10-01 at 13:18, David Megginson wrote:
> Andy Ross writes:
>
> > If X refers to a position in meters, then X dot is the velocity in
> > m/s, and X dot dot is the acceration in m/s^2, etc... This is
> > presuming that the second is the canonical time unit (which it is).
>
> So, w
On Tue, 2002-10-01 at 12:50, Andy Ross wrote:
> David Megginson wrote:
> > In flight.hxx, some of the *dot* values are referred to as 'rates',
> > and some are referred to as 'accelerations' (i.e. rate of change in
> > rate of change). So, here are some specific questions:
>
> Strictly, the dot
On Tue, 2002-10-01 at 10:06, Andy Ross wrote:
> Norman Vine wrote:
> > FWIW - I really don't understand why the FDM folks haven't been using
> > this as I wrote it several years ago so that one could get an
> > elevation per wheel
I have to say, here, that this topic has always stirred up debate
Does anyone have any experience with moving from Doc++ to
Doxygen? I'm thinking of making the move. Doxygen seems to
be what I had hoped Doc++ would become, but seems to have
stalled. It looks like many of the identifiers are the
same.
Jon
___
Flig
David Megginson writes:
> Norman Vine writes:
>
> > What happened to all of the documentation that I provided for MY
> > MATRIX routines that the 3-D Model code uses
> >
> fgfs-matrix-howto.html
>
> or something similar. Inline comments have some value when they can
> be extracted with a Ja
Just to let everyone know, I haven't given up on the Spitfire model.
I've been looking for new accomodation, now that's found I anticipate
I'll be without internet for a 2 week period (or less). It looks like I
can get ADSL this time, fingers crossed.
Later,
Chris.
_
David Megginson writes:
> Norman Vine writes:
>
> > What happened to all of the documentation that I provided for MY
> > MATRIX routines that the 3-D Model code uses
>
> A while ago I deleted some dead, commented-out code but have tried to
> avoid usage comments (i.e. "this function does X us
Well hmmm... I don't think any harm was meant by David's comment. If anything
he pointed out the lack of his own doc work. In any case it did take many
hours to figure out how to fix that viewer problem. The only reason I did
find it was because all the reported viewer bugs traced back to the
Andy Ross writes:
> If X refers to a position in meters, then X dot is the velocity in
> m/s, and X dot dot is the acceration in m/s^2, etc... This is
> presuming that the second is the canonical time unit (which it is).
So, would these property names be acceptable?
/orientation/rates/ang
Norman Vine writes:
> What happened to all of the documentation that I provided for MY
> MATRIX routines that the 3-D Model code uses
A while ago I deleted some dead, commented-out code but have tried to
avoid usage comments (i.e. "this function does X using parameters Y
and Z and returns A")
Andy Ross writes:
>
> For reference, YASim does all of its internal mechanics in a
> geocentric cartesian coordinate system. It never usees anglular
> measures except at the interface level. In these coordinates, the
> aircraft state is pleasingly simple:
>
> position: 3 doubles
> orientatio
David Megginson wrote:
> In flight.hxx, some of the *dot* values are referred to as 'rates',
> and some are referred to as 'accelerations' (i.e. rate of change in
> rate of change). So, here are some specific questions:
Strictly, the dot notataion refers to time derivative. So, if you
have a va
David Megginson writes:
>
> I'm hitting a wall with my limited knowledge of calculus.
David
You REALLY NEED to read this book !!
- Original Message -
From: "Norman Vine" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 30, 2002 7:23 PM
Subject: [Flightgear-devel] 13.4
David Megginson writes:
>
> Norm, it depends a lot on documentation. There is far more code in
> SimGear and FlightGear than most people know about or understand.
> While I don't always keep it up to date, my 3-D model code and
> property code gets used mainly because I provided documentation to
Once upon a time, you were sitting and writing:
> > I think "dot" means 'rate of change in' or 'derivative'. latitude-dot
> > would be the rate of change in latitude. I.e. latitude is a position,
> > latitude-dot is a velocity. If you had velocity-down (earth centered
> > coordinates) then vel
Norman Vine writes:
> I really am beginning to wonder if anyone actually tries using
> the code we already have in place for doing these things !!!
Norm, it depends a lot on documentation. There is far more code in
SimGear and FlightGear than most people know about or understand.
While I don'
Andy Ross writes:
> This is true, but it's handlable. The way the Gnome i18n stuff works,
> the program is guaranteed to have american English text for
> everything. These strings are often hardcoded, and are used as the
> hash keys for translation lookups. So, in the worst case situation, a
>
Curtis L. Olson:
> Well the difference is if you have one menu.xml for each languange,
> then when someone adds a new option to the default menu.xml and
> forgets to add it to all the other languange's menu.xml files you have
> a problem and you are headed towards a big mess.
This is true, but it
Erik Hofman writes:
> I don't get the point;
>
> 1. parts of the second xml file will *overwrite* previously read sections.
>
> 2. new parts added in the _first_ xml file will show up in English.
>
> This is what you are aiming for ins't it?
Well, ok sure, it just seems less optimal and involv
Curtis L. Olson wrote:
> Erik Hofman writes:
>>Curtis L. Olson wrote:
>>
>>>If we have one menu.xml file and one options.xml file, then one
>>>".xml" file per language, then a person adding a menu
>>>option or adding a command line option only needs to add it to the one
>>>main xml file, and to th
Andy Ross
> Norman Vine wrote:
> > FWIW - I really don't understand why the FDM folks haven't been using
> > this as I wrote it several years ago so that one could get an
> > elevation per wheel
>
> Landing gear struts compress, so there isn't a single point of
> intersection. Worse, they don't
Erik Hofman writes:
> Curtis L. Olson wrote:
> > Erik,
> >
> > THe only thing I'm concerned about is if we have 10 different
> > menu..xml files and then we want to do some work on the
> > GUI, the person doing this needs to make the change in 10 different
> > places, and in 9 languages they are
On Tue, Oct 01, 2002 at 10:18:36AM -0500, Curtis L. Olson wrote:
> David Megginson writes:
> > I'm hitting a wall with my limited knowledge of calculus.
> > Specifically, I'm looking at the following:
> >
> > - latitude-dot
> > - longitude-dot
> > - radius-dot
> > - v-dot-local
> > - v-dot-body
>
Curtis L. Olson wrote:
> Erik,
>
> THe only thing I'm concerned about is if we have 10 different
> menu..xml files and then we want to do some work on the
> GUI, the person doing this needs to make the change in 10 different
> places, and in 9 languages they are unfamiliar with.
>
> If we have o
Curtis L. Olson wrote:
> http://www.flightgear.org/Docs/Flight/LaRCsim/LaRCsim-vars/LaRCsim-vars.html
>
> (This is a latex conversion of the original excel spread sheet which I
> don't think I have anymore.)
This one should be in the CVS of the Docs:
./CVS/fgfs/docs/FDM/LaRCsim/LaRCsim_generics
Michael Basler writes:
> >From a user's perspective, a clever solution might be having a menu entry
> "Language" which defaults to English, but can be changed to French,
> German... The selection would then select the proper xml files for diplaying
> menu, messages etc. There are several prog
Norman Vine wrote:
> FWIW - I really don't understand why the FDM folks haven't been using
> this as I wrote it several years ago so that one could get an
> elevation per wheel
Landing gear struts compress, so there isn't a single point of
intersection. Worse, they don't always point down. Even
Frederic BOUVIER writes:
> Curtis L. Olson <[EMAIL PROTECTED]> wrote :
>
> > The strings-fr.xml file would look something like (according
> > to babelfish):
> >
> > Dossier
> > Economiser le vol
> > Vol de charge
> > Remise
>
> babelfish is very funny ;-)
"Economiser le vol
Hi,
>From a user's perspective, a clever solution might be having a menu entry
"Language" which defaults to English, but can be changed to French,
German... The selection would then select the proper xml files for diplaying
menu, messages etc. There are several programs having this, e.g. Ghostvie
Curtis L. Olson <[EMAIL PROTECTED]> wrote :
> The strings-fr.xml file would look something like (according
> to babelfish):
>
> Dossier
> Economiser le vol
> Vol de charge
> Remise
babelfish is very funny ;-) Hopefully, someone already offered to help
translating.
Fichier
Sauver l
David Megginson writes:
> I'm hitting a wall with my limited knowledge of calculus.
> Specifically, I'm looking at the following:
>
> - latitude-dot
> - longitude-dot
> - radius-dot
> - v-dot-local
> - v-dot-body
> - alpha-dot
> - beta-dot
> - phi-dot
> - theta-dot
> - psi-dot
I think "dot" mean
I'm hitting a wall with my limited knowledge of calculus.
Specifically, I'm looking at the following:
- latitude-dot
- longitude-dot
- radius-dot
- v-dot-local
- v-dot-body
- alpha-dot
- beta-dot
- phi-dot
- theta-dot
- psi-dot
In flight.hxx, some of the *dot* values are referred to as 'rates',
Richard Bytheway writes:
> Sounds sensible.
>
> Could the appropriate text..xml file be determined
> automatically in a repeatable, portable way at runtime (with
> optional override of course)?
> Perhaps if were the country code, or at least derived
> from it?
>
> Would this, or a similar sc
David Megginson writes:
> Curtis L. Olson wrote:
>
> > Having given a very tiny bit of thought to 'internationalizing'
> > flightgear I thought perhaps a first start would be to provide
> > translated versions of menu.xml and options.xml
>
> I'm looking forward to the Minnesotan translation.
Erik,
THe only thing I'm concerned about is if we have 10 different
menu..xml files and then we want to do some work on the
GUI, the person doing this needs to make the change in 10 different
places, and in 9 languages they are unfamiliar with.
If we have one menu.xml file and one options.xml fi
Curtis L. Olson wrote:
> Having given a very tiny bit of thought to 'internationalizing'
> flightgear I thought perhaps a first start would be to provide
> translated versions of menu.xml and options.xml
I'm looking forward to the Minnesotan translation. Will it sound like
Prairie Home Compa
Hi Curtis, hi to all,
When you'll be OK on the way to translate FlightGear, I could do the
french translation.
I'm OK for the way below, but I couldn't have a good advice, I'm not dev ;-)
Bye,
Fabien
Curtis L. Olson wrote:
> Having given a very tiny bit of thought to 'internationalizing'
> fl
Jim Wilson writes:
>
> Norman Vine <[EMAIL PROTECTED]> said:
>
> > If it isn't then you just need to load it before making your query to
the
> > elevation routine and then it should just work using a similar method to
> > what Jim uses for Tower placement
> >
>
> Actually it is used to get the gro
Curtis L. Olson wrote:
> Having given a very tiny bit of thought to 'internationalizing'
> flightgear I thought perhaps a first start would be to provide
> translated versions of menu.xml and options.xml
>
> It would be nice to do this in a sensible organzied way so that when
> we add a menu opti
Sounds sensible.
Could the appropriate text..xml file be determined automatically in a
repeatable, portable way at runtime (with optional override of course)?
Perhaps if were the country code, or at least derived from it?
Would this, or a similar scheme, also be suitable to localise the keybo
56 matches
Mail list logo
