Gerard Robin wrote:
It do not solve the Atlas problem.
Only one way to run atlas map is to use the old Airports format data.
Atlas is a very old program which is partly obsolete regarding FGFS.
Well, If you want Atlas to work with the kates data you will need to fix
it, don't you?
I've
Jon Berndt wrote:
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.
The real problem was snprintf(...) which isn't availble under Winodws:
#if defined(_WIN32)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Erik Hofman schrieb:
Jon Berndt wrote:
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.
sprintf is C standard - and very
Christian Mayer wrote:
The real cross platform soultion would be the C++ std::string
No, you can't format (the f in printf) the string using the default C++
string class).
Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Erik Hofman schrieb:
Christian Mayer wrote:
The real cross platform soultion would be the C++ std::string
No, you can't format (the f in printf) the string using the default C++
string class).
You have to use the I/O manipulators
On Mon, 2005-07-25 at 17:13, Andy Ross wrote:
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?
Yes.
If nothing else, we can
certainly solve it by brute-force integrating it for +/- a few
Steve Hosgood wrote:
If it's just a case of changing ecliptic_to_equatorial(), julian_date(),
and GST() then I'm up for it.
We got routines for thee julian date and GST dated already in
SimGear/simgear/timing/sg_time.[ch]xx
Can someone confirm that doing this will fix the issue, or is
On Tue, 2005-07-26 at 10:37, Erik Hofman wrote:
To prevent any problems in the future I would like to see that file
removed and the functions added to tmp.[ch]xx
Remove sunpos.[ch]xx completely? OK.
But what is really needed is a way to get sun_angle() working in
sunsolver.cxx which is
No, you can't format (the f in printf) the string using the default C++
string class).
You have to use the I/O manipulators (Stroustrup: 21.4.6.2, page 633ff.)
like std::setprecision().
The string class cannot create a string representation of a floating point
number as far
as I can tell.
Hi,
I have been trying to install the FGFS on my PC but I am having problem to
configure the DEBIAN packages on the proper order before I start the FGFS
packages installation.
Is there a quick setup that I could use?
I am doing the installation thru network, I downloaded the newest Minimal
Le mardi 26 juillet 2005 à 09:46 +0200, Erik Hofman a écrit :
Gerard Robin wrote:
It do not solve the Atlas problem.
Only one way to run atlas map is to use the old Airports format data.
Atlas is a very old program which is partly obsolete regarding FGFS.
Well, If you want Atlas to
Le lundi 25 juillet 2005 à 23:55 +0200, Gerard Robin a écrit :
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
Christian Mayer wrote:
You have to use the I/O manipulators (Stroustrup: 21.4.6.2, page 633ff.)
like std::setprecision().
Compared to the fast printf syntax they are too annoying to write and
not that flexible, but they are more readable and they can be combined
to your own user defined I/O
Le mardi 26 juillet 2005 à 15:16 +0200, Gerard Robin a écrit :
Le lundi 25 juillet 2005 à 23:55 +0200, Gerard Robin a écrit :
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
On Tuesday 26 July 2005 00:02, Gerard Robin wrote:
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?
Le mardi 26 juillet 2005 à 16:40 +0200, Roy Vegard Ovesen a écrit :
On Tuesday 26 July 2005 00:02, Gerard Robin wrote:
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
Le mardi 26 juillet 2005 à 17:04 +0200, Roy Vegard Ovesen a écrit :
On Tuesday 26 July 2005 15:16, Gerard Robin wrote:
I am not fully sure,
but it is probably coming from an old update, because every July CVS
releases does not work (i keep it).
??? Do you keep every July CVS release for
Le mardi 26 juillet 2005 à 18:05 +0200, Gerard Robin a écrit :
Le mardi 26 juillet 2005 à 17:04 +0200, Roy Vegard Ovesen a écrit :
On Tuesday 26 July 2005 15:16, Gerard Robin wrote:
I am not fully sure,
but it is probably coming from an old update, because every July CVS
releases does
From: Roy Vegard Ovesen
On Tuesday 26 July 2005 00:02, Gerard Robin wrote:
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
Steve Hosgood wrote:
Funnily enough, I was just having a cup of tea and reading that very
file just as your email came in (you're in Europe I presume?).
Yep.
fgSunPositionGST seems to be derived from Johnson's 'xearth' code, but
it calculates where on earth the sun is directly overhead.
On Tuesday 26 July 2005 18:25, Gerard Robin wrote:
Hi Roy
I have got the answer the electrical nasal file must include the short
term patch 28 = 60 ideal volts with rpm_source : /engines/engine
[0]/rpm
In theory this hould not make any dfference because the gps is not as
demanding as the
Le mardi 26 juillet 2005 à 18:45 +0200, Roy Vegard Ovesen a écrit :
On Tuesday 26 July 2005 18:25, Gerard Robin wrote:
Hi Roy
I have got the answer the electrical nasal file must include the short
term patch 28 = 60 ideal volts with rpm_source : /engines/engine
[0]/rpm
In theory this
...
This bug showed up about 10 days ago with an update from cvs. Any ideas
what is broken?
I've got a hunch. Dave Culp may have an idea. I'll take a look, too.
Sorry. I haven't been following the FG CVS logs.
Dave
___
Flightgear-devel
In theory this hould not make any dfference because the gps is not as
demanding as the turn indicator. The gps should work with any electrical
input larger than 0. So it should work just as well on 28 as on 60. But
hey,
if you say it's working now, then who am I to dispute that? ;-)
On Tuesday 26 July 2005 19:20, Gerard Robin wrote:
If we look at /systems/electrical/outputs/
we get gps to null when volt=28
we get gps to 60 when volt=60
in gps.cxx we find Line 102
_electrical_node = fgGetNode(/systems/electrical/outputs/gps, true);
That's the initialization of the
On Tuesday 26 July 2005 11:30, Steve Hosgood wrote:
So we're just down to the problem that the sun position code is possibly
not GPL-able. I've dug out my own code that I'm quite happy to donate.
Only part of 'src/Time/sunpos.cxx' seems to be derived from Kirk
Johnson's 'xearth' anyway, and
Dave Perry wrote:
This bug showed up about 10 days ago with an update from cvs. Any
ideas what is broken?
Regards,
Dave Perry
I have started to investigate that problem but not found anything atm.
I can reproduce the bug in the same situation as you.
FG is *not* freezed. All (?) is working
On Sunday 24 Jul 2005 17:30, Erik Hofman wrote:
Lee Elliott wrote:
p.s. Erik: someone on the user list wants to stop the
YASim legacy engine definition message from your pa28. I
can have a look at it if you want but I know it's really
your baby:)
Eh, no, It's David Meggison's model.
On Tuesday 26 Jul 2005 12:43, [EMAIL PROTECTED] wrote:
Hi,
I have been trying to install the FGFS on my PC but I am
having problem to configure the DEBIAN packages on the proper
order before I start the FGFS packages installation.
Is there a quick setup that I could use?
I am doing the
Hi,
sorry for the late reaction.
Turns out to be a bad interaction between jsbsims crash detection and my
past initialization changes.
The attached patch fixes this by moving crash detection out of the
initialization phase of jsbsim.
Erik,
Can you apply that please to flightgears cvs.
I will
Le mardi 26 juillet 2005 à 23:13 +0200, Mathias Fröhlich a écrit :
Hi,
sorry for the late reaction.
Turns out to be a bad interaction between jsbsims crash detection and my
past initialization changes.
The attached patch fixes this by moving crash detection out of the
initialization phase
31 matches
Mail list logo
