On Monday 02 July 2007 10:05, Melchior FRANZ wrote:
> Yeah. It's also not only the Traffic Manager. FlightGear is full
> of exit()s, when there should really be one single exit() at most,
> and that would be in bootstrap.cxx. When the project was started,
> gcc wasn't what it is now. I think templa
On Tuesday 03 July 2007 00:20, Vivian Meazza wrote:
> > > > > > "Vivian Meazza" wrote:
> > > > > > > What were we saying about incompletely tested and poorly
> > > > > >
> > > > > > ^^
> > > > > >
[Lot's a latin skipped for clarity]
>
> Perhaps you recall this thread: "C++ code beaut
> NVIDIA-Linux-x86-100.14.11-pkg1.run is much newer than
> NVIDIA-Linux-x86-1.0.9755-pkg1.run
>
> http://www.nvidia.com/object/linux_display_ia32_100.14.11%20.html
FWIW, I'm using 100.14.09 and i can still get the issue with FG plib.
> I actually thought this was an OSG problem, but you're r
On Mon, 2007-07-02 at 16:33 -0700, Bohnert Paul wrote:
> Everyone,
>
> I'm running 0.9.11pr1, Fedora 4 with a Nvidia video card.
>
> I'm not sure if this is a Nvidia issue or a FlightGear issue.
>
> I replace my old Nvidia card a new Nvidia card. I installed the latest
> driver from the Nvidia
>I'm not sure if this is a Nvidia issue or a FlightGear issue.
You might want to refer to this thread:
http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg10644.html
The bottom line is, we're not sure if it's FG or nvidia. But it does
happen only in certain ver
As you presumably know, the gui, as embodied in the weather-conditions
popup, weather.xml, assumes a multi-layer model of the atmosphere.
The same assumption can be found in much of the back-end code.
Today I call attention to the code near line 715 in
Environment/environment.cxx
void
interpolate
Everyone,
I'm running 0.9.11pr1, Fedora 4 with a Nvidia video card.
I'm not sure if this is a Nvidia issue or a FlightGear issue.
I replace my old Nvidia card a new Nvidia card. I installed the latest driver
from the Nvidia web page NVIDIA-Linux-x86-1.0.9755-pkg1.run.
This was the res
Hi Hans,
>> I checked out the source files including 0.9.11-pre1, SimGear-0.3.11-
>> pre1, and Plib-1.8.4. SimGear-0.3.11 doesn't include the alut.h fix,
>> so it works with self-compiled freeglut as you wrote before, but I
>> don't think many users will do that so I decide to provide patches
>> f
Martin Spott
> Sent: 02 July 2007 22:45
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] crash in AI traffic
>
>
> "Vivian Meazza" wrote:
> > Martin Spott
> > > Sent: 02 July 2007 16:32
> > > "Vivian Meazza" wrote:
> > > > Martin Spott
> > > > > "Vivian Meazza" wrot
Bug #1:
Every time you look at /sim/logging/classes it gets longer, without bound.
To see for yourself, start
FGFS --httpd=5400
Then use the File :: browse_internal_properties popup.
Browse over to the /sim/logging directory, and just leave it there for
a few minutes.
Meanwhile, use a web br
"Vivian Meazza" wrote:
> Martin Spott
> > Sent: 02 July 2007 16:32
> > "Vivian Meazza" wrote:
> > > Martin Spott
> > > > "Vivian Meazza" wrote:
> >
> > > > > What were we saying about incompletely tested and poorly
> > > > ^^
> > > > > reviewed code getting into cvs ... ?
> > > >
> >
Martin Spott
> Sent: 02 July 2007 16:32
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] crash in AI traffic
>
>
> "Vivian Meazza" wrote:
> > Martin Spott
> > > "Vivian Meazza" wrote:
>
> > > > What were we saying about incompletely tested and poorly
> > >
Hi Georg,
Georg Vollnhals wrote:
> nice offer, thank you. The very first idea I had reading your first
> message was that this could be a great tool for creating big forrests -
> placing the trees within the outer boarders by a script (creating the
> *.stg part) is easy, the "on ground placement"
Sebastian Bechtold schrieb:
> I'll try to make some changes suggested by Martin to the patch and then
> post it again (the first version attachment was scrubbed by the mailing
> list manager anyway). I can also send you an "exclusive preview version"
> (which, as for the effect, already works perfe
I have edited some files in my 787 model.
http://www.golffoxtrotsierra.741.com/787.zip
787/787.xml modified to more accurately reflect the characteristics of the 787.
Slight modifications made to 787-set.xml, 787.ac (including engines, pylons,
and stablizers), Models/787.xml, hud.ac, and hud.xm
On Monday 02 July 2007 13:25, Vivian Meazza wrote:
> I am one of those developers who have the traffic manager turned off. I
> have taken the trouble sometime ago to inform Durk directly, so he is well
> aware of this bug. Along with the one which causes AITankers to move at
> warp speed factor 2.
On 7/1/07, gh.robin wrote:
On Sun 1 July 2007 12:32, Martin Spott wrote:
> "gh.robin" wrote:
> > Here the snapshot which shows the difference
> >
> > http://perso.orange.fr/GRTux/FG-OSG-SeaTexture.jpg
>
> Probably a mixup in the materials definition, 'materials.xml' ?
>
> Martin.
One o
"Vivian Meazza" wrote:
> Martin Spott
> > "Vivian Meazza" wrote:
> > > What were we saying about incompletely tested and poorly
> > ^^
> > > reviewed code getting into cvs ... ?
> >
> > -> Plural majestatis ?
> Haud. Ego relatum ut an mane sermo.
Qui participavit in conclusio illa
Hi Lee,
Am Montag, den 02.07.2007, 15:57 +0100 schrieb leee:
> While YASim is a very good fdm, imo (and I've done a few in my time), it
> isn't
> suited to accurately portraying a glider because the 'cruise' definitions
> don't apply. The cruise section assumes level flight and needs to know t
Martin Spott
> Sent: 02 July 2007 15:42
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] crash in AI traffic
>
>
> "Vivian Meazza" wrote:
>
> > What were we saying about incompletely tested and poorly
> reviewed code
> ^^
> > getting into cvs ... ?
>
While YASim is a very good fdm, imo (and I've done a few in my time), it isn't
suited to accurately portraying a glider because the 'cruise' definitions
don't apply. The cruise section assumes level flight and needs to know the
power required to maintain that level flight for it to work correct
* Melchior FRANZ -- Monday 02 July 2007:
> I would definitely not ignore a message from the traffic manager:
>
> Traffic Manager problem in src/Traffic/TrafficMgr.cxx, line 341:
> routing problem in EHAM data -- no endpoint found
OK, here's the first addition: I've just added a macro SG_ORIGIN
"Vivian Meazza" wrote:
> What were we saying about incompletely tested and poorly reviewed code
^^
> getting into cvs ... ?
-> Plural majestatis ?
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
-
On 7/2/07, Durk Talsma <[EMAIL PROTECTED]> wrote:
> I agree that it can be very frustrating to have a flightgear session cancelled
> due to an exit, and in a released version, this should be avoided. However,
> the flip side is that if we continue to "gracefully recover", its going to be
> a lot to
Am Montag 02 Juli 2007 15:04 schrieb Vivian Meazza:
> Good. Phew. No callsign in the flightplans?
I think the properties are not updated. Internally they are set at least on
loading the xml file. ATM I'm guessing though.
> I couldn't compare with
> earlier, since today is the first time I have
On 7/2/07, Hans Fugal <[EMAIL PROTECTED]> wrote:
> I haven't looked at the radar stuff yet, so I'm just going from what
> you've said here. VORs are slaved to a certain variation, presumably
> the magnetic variation at the time they were put into service (or last
> updated). But as the magnetic var
On 7/2/07, K. Hoercher <[EMAIL PROTECTED]> wrote:
> You can see this if you enable the showing of a tacan source in the
> radar and its corresponding data/symbol whatever box. They appear to
> "point" into different directions. I suspect both informations get
> derived by ways taking the magnetic v
While there's so much hacking happening wrt to radar instrumentation,
I'd like note a small observation. There seems to be a small, but
noticeable, inconsistency about the heading displayed.
You can see this if you enable the showing of a tacan source in the
radar and its corresponding data/symbol
Thomas Förster
> Sent: 02 July 2007 13:41
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
>
>
> >
> > No callsigns from the Traffic Manager stuff - did we break that?
>
> Probably not, never seen any... (so, if broken, not with the
>
I wrote
> Sent: 02 July 2007 13:15
> To: 'FlightGear developers discussions'
> Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
>
>
> Csaba Halász
>
> > Sent: 01 July 2007 21:12
> > To: FlightGear developers discussions
> > Subject: Re: [Flightgear-devel] [ANN] OSG - Improved
>
> No callsigns from the Traffic Manager stuff - did we break that?
Probably not, never seen any... (so, if broken, not with the wxradar patch)
Thomas
--
PhD Student, Dept. Animal Physiology, HU Berlin
Tel +49 30 2093 6173, Fax +49 30 2093 6375
Csaba Halász
> Sent: 01 July 2007 21:12
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
>
>
> Hello!
>
> Here is a new version of my radar patch.
> *** This is still for OSG only ***
>
> Theoretically the ai.diff & wxradar.diff can b
> The time ( and Jon :) ) is (are) working for us , wouldn't the
> coming external forces within JSBSim solve these aerotow and winch starts
> funct (and others.)
>
> Regards
>
> Gérard
Yes, Dave Culp has done a lot of work on this, and I am continuing it, but I
don't have an idea when i
Martin Spott wrote
> Sent: 02 July 2007 09:25
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] crash in AI traffic
>
>
> Melchior FRANZ wrote:
>
> > Several people (mostly developers) on IRC have stated that
> they have
> > the traffic manager turned off because
On Mon 2 July 2007 10:10, Martin Spott wrote:
> Detlef Faber wrote:
> > Am Montag, den 02.07.2007, 00:43 + schrieb Martin Spott:
> > > The in-flight behaviour of the YASim FDM is, similar to that of the
> > > 'Bocian', extremely 'direct' and unforgiving. As an alternative you
> > > might do bet
> Thoughts, ideas, objections?
Though the property system is probably nice, why not just raise an exception +
a catch all error handler. In release code this probably just logs a warning,
whereas in debug/development code it exits (could be a commandline option).
This works for all subsystems a
Am Montag, den 02.07.2007, 08:10 + schrieb Martin Spott:
> Detlef Faber wrote:
> > Am Montag, den 02.07.2007, 00:43 + schrieb Martin Spott:
>
> > > The in-flight behaviour of the YASim FDM is, similar to that of the
> > > 'Bocian', extremely 'direct' and unforgiving. As an alternative you
Melchior FRANZ wrote:
> Several people (mostly developers) on IRC have stated that they have
> the traffic manager turned off because [...]
If you're really that serious about it, then you might start to help
getting the thing into better shape by asking these people to report
properly on this ve
Hi,
At first thanks for uploading and correcting the
error.
How is the behaviour of a glider in flight?
If YASim is a good fdm, it should simulate the
behaviour with the right data correct.
I see more problems in the simulating of the
enviroment like thermals, turbulences, wind etc
Greeting
>
> Hi Sebastian,
>
> as someone doing a lot of scenery work I really like your idea which
> could make things easier for some objects.
>
> The problem was - after my view - that you typed "< " and not " <
> -".
> Your new post corrects this, the implementation should be possible
> without
* Melchior FRANZ -- Monday 02 July 2007:
> Sure, a property that turns every serious exception into a segfault
> couldn't hurt. A segfault, not an abort()!
Uh, I know: An abort() *makes* a coredump. I meant an exit(). :-)
m.
--
Detlef Faber wrote:
> Am Montag, den 02.07.2007, 00:43 + schrieb Martin Spott:
> > The in-flight behaviour of the YASim FDM is, similar to that of the
> > 'Bocian', extremely 'direct' and unforgiving. As an alternative you
> > might do better by using a derivative of the JSBsim FDM as used in
* Durk Talsma -- Monday 02 July 2007:
> I will look into that. FWIW, most of the exit()' s in the code were placed
> there during the early stages of development, and anyone of those remaining
> is in a spot where the probability of an error has become extremely small Or
> just nobody is reporti
Am Montag, den 02.07.2007, 00:43 + schrieb Martin Spott:
> Hi Heiko,
>
> Heiko Schulz wrote:
>
> > The YASim-FDM is lacking - I don't know how to match
> > this to the real perfomance...
>
> The in-flight behaviour of the YASim FDM is, similar to that of the
> 'Bocian', extremely 'direct' an
44 matches
Mail list logo
