On July 25, 2005 06:42 am, Vivian Meazza wrote:
> Radar Echoing Area is (REA) and is also known as the Radar Cross Section
> (RCS). It's not quite the same thing as the radar visibility range.
>
> RCS is a property of the target, and varies with the target aspect w.r.t.
> the radar, and also the ra
IIRC, sprintf was a problem for some. Is that still the case? I've compiled
under Cygwin,
Borland C++, and I think I've also compiled code that uses sprintf under IRIX.
Jon
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.
> I don't know if there are others that use fgfs from front range
> locations in Colorado, but I use it to practice instrument approaches in
> this my home area and my two favorite aircraft for this are the c172p
> and c310, both jsbsim models. _The yasim aircraft still work fine with
> this s
I have posted this issue twice before. This is with plib, SimGear, fg,
and data all from recent cvs. I have fgfs from cvs up-to-date on my
desktop and notebook, both running Linux FC3 and both have this bug
after updates from about 10 days ago.
I don't know if there are others that use fgfs
> From: Josh Babcock
>
> Jim Wilson wrote:
> > Hi Josh,
> >
> > These entries in your example...
> >
> > instrumentation/nav[0]/gs-needle-deflection
> > 1
> >
> > ...assume that your gs-needle-deflection property is in degrees. Maybe
> > that property needs to be renamed with a -deg
> suffix.
Jim Wilson wrote:
> Hi Josh,
>
> These entries in your example...
>
> instrumentation/nav[0]/gs-needle-deflection
> 1
>
> ...assume that your gs-needle-deflection property is in degrees. Maybe that
> property needs to be renamed with a -deg suffix.
Well, that doesn't seem to exist, though it
Le lundi 25 juillet 2005 à 09:38 +0200, Erik Hofman a écrit :
> Markus Morawitz wrote:
>
> > Please can anyone help me by teaching me some history
> > about the Airport and NavAids file formats.
> > Where is the current file format being described?
>
> FlightGear started out by using a native fil
Le lundi 25 juillet 2005 à 23:02 +0200, Roy Vegard Ovesen a écrit :
> AFAICT there hasn't been any significant changes to Instrumentation/gps.*xx
> or
> Airports/simple.*xx. There has been alot of improvements to the gui system
> lately, so maybe my dialog has become broken. Could you try to tr
On Monday 25 July 2005 20:49, Gerard Robin wrote:
> Get Nearest Airport (From Menu Equipment GPS) seems not working.
> It was working with olders CVS.
> Is it any new modifications which deleted that function ?
AFAICT there hasn't been any significant changes to Instrumentation/gps.*xx or
Airport
Get Nearest Airport (From Menu Equipment GPS) seems not working.
It was working with olders CVS.
Is it any new modifications which deleted that function ?
Thanks
--
Gerard
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.
I wrote:
> that, too, can be done in cartesian space and doesn't require a
> nothing of "sunrise/set" time).
Heh, s/nothing/notion/
Most of my typos are clear from context, but that one reads like
gibberish, sorry. :)
Andy
___
Flightgear-devel mailing
Steve Hosgood wrote:
> Solving where the planet is in its orbit for any given calendar time
> is tricky.
This is just the equal area thing, right? (angular orbital velocity
goes as the inverse of the distance to the focus) I kinda-sorta
remember doing a parameterization of that in college way back
On Mon, 2005-07-25 at 15:17, Andy Ross wrote:
> I humbly submit that this is yet another area where an Euler (angle)
> representation is a bug, not a feature. We have a sane cartesian
> coordinate system for the earth. All that's needed is to define one
> for the solar system* and then do reasona
Steve Hosgood wrote:
> The position of any astronomical object relative to a viewer standing on
> the planet's surface is usually given as "altitude" and "azimuth" - with
> the true horizon and true "North" used as the references.
> [...]
> Additional entertainment will be provided by the fact that
Jon Berndt wrote:
> Can anyone differentiate for me the concept of "position" as
> contrasted to "index" in this situation?
Position is arbitrary. I think it corresponds to the order of which
the nodes were added to the parent. The only use I can think of for
this method is enumerating over all
Oliver Schroeder wrote:
> 2) A "visibility" range (Vivian called it "Radar Echoing Area"),
> provided by aircraft model data. That way a eg. 747 can show up on
> radar earlier than a cessna, making radar more real.
> 3) A radio transmission range, i.e. the range a client is able to reach
> via rad
> From: Lee Elliott
>
> What I've been thinking recently about 3d models is that it might
> be best to make the panel and interior first, and then model the
> exterior to fit it. I say this because after making an external
> model that appears to fit the 3-views, if there's any real
> curvat
Jon Berndt wrote:
In props.cxx I find this code:
/**
* Get a child node by position (*NOT* index).
*/
SGPropertyNode * getChild (int position);
Can anyone differentiate for me the concept of "position" as contrasted to
"index" in this
situation?
A position and index or not necessa
On Mon, 2005-07-25 at 10:35, Erik Hofman wrote:
> Steve Hosgood wrote:
>
> > Erik:
> > The position of any astronomical object relative to a viewer standing on
> > the planet's surface is usually given as "altitude" and "azimuth" - with
> > the true horizon and true "North" used as the references.
Hi Josh,
These entries in your example...
instrumentation/nav[0]/gs-needle-deflection
1
...assume that your gs-needle-deflection property is in degrees. Maybe that
property needs to be renamed with a -deg suffix.
You used min and max instead of min-deg and max-deg when configuring a
rotation
In props.cxx I find this code:
/**
* Get a child node by position (*NOT* index).
*/
SGPropertyNode * getChild (int position);
Can anyone differentiate for me the concept of "position" as contrasted to
"index" in this
situation?
Jon
___
Fl
Oliver Schroeder
... snip ...
> >
> The version field is a good idea. And I have another suggestion. There
> should be a "info" packet, containing details of the client. I'm not
> sure what information should be sent to call the packet "complete", but
> I have some ideas of what should be inclu
Steve Hosgood wrote:
Erik:
The position of any astronomical object relative to a viewer standing on
the planet's surface is usually given as "altitude" and "azimuth" - with
the true horizon and true "North" used as the references. Normally, an
object is said to "set" when it crosses the visible
Mathias Fröhlich wrote:
>What is missing is a clear architecture indenpendent definition of the storage
>layout
>Also a 'protocol version' field in the message header will be a good idea IMO.
>That way clients could distinguish if and how they should look at that binary
>chunk.
>
>
The ve
On Fri, 2005-07-22 at 17:56, Erik Hofman wrote:
> Andy Ross wrote:
> > Erik Hofman wrote:
> >
> >>Since you are already familiar with this stuff, I need the function to
> >>calculate the sun position (in degrees or radians) above the horizon
> >>at a certain time/lat/lon. What is this normally cal
Markus Morawitz wrote:
Please can anyone help me by teaching me some history
about the Airport and NavAids file formats.
Where is the current file format being described?
FlightGear started out by using a native file format for airport data
but recently switched to the file format also used b
Paul Kahler wrote:
>All this multiplayer "chat" stuff has me thinking "game". It would
>probably be more in line with simulation if chatting took place on a
>simulated radio. You'd not only have to be close enough to someone, but
>you'd have to be on the same frequency in order to talk to them. Th
27 matches
Mail list logo
