Update:
I now have a workaround configuration that at least allows
me to park without anything too terrible happening. The
sim will run for an hour, even with the FPE trap enabled.
This workaround configuration (call it X) entails:
1) Passing *no* options on the command line, using
options in
Hi,
On Sunday 13 December 2009 01:49:47 am Ron Jensen wrote:
On Sat, 2009-12-12 at 16:21 -0700, John Denker wrote:
--prop:/sim/ai-traffic/enabled=0
--prop:/sim/traffic-manager/enabled=0
Just to clarify:
The AI system that is generating the NaNs, is the old one (i.e. code contained
in
Hi,
My experience was, that this NaN's only appear with
--prop:/sim/ai-traffic/enabled=1 on win32. All other things seems not to
produce NaN's.
Btw I wonder if we still need ai-traffic, as the interactive traffic works so
much better and more nice?
Cheers
HHS
Update:
I now have a
John Denker wrote:
I have some basic questions about the --metar command-line
option.
AFAICT the getstart.pdf manual doesn't mention this option.
That's correct - we've still to complete the updates to the manual
for the upcoming release. However, it's on my TODO list.
If you want to
John Denker wrote:
Update: To observe this bug, I don't even need to taxi.
I can just sit at the starting point of runway 31L at
JFK with the engine off. After sitting about 8 minutes,
I observe nan messages on the console.
Jon, could you specify if this was with 'real' weather enabled
I never have the ai traffic enabled, but still get nans sometimes. The
ai traffic may be triggering a nan, but I'm not sure it's actually the
root cause. Debugging nans can be a real pita, with every operation
against a nan producing a nan they spread like wildfire. By the time
it causes a problem
Folks,
Just following up on this old thread, we now have some new insights into FPS,
as recently posted in the forum:
On Sunday 25 October 2009 04:39:48 pm I wrote:
...to think of it from an advertising point of view: What does every company
in the world do to advertise their product?
Hi,
On Sunday 13 December 2009 09:53:49 am Heiko Schulz wrote:
Hi,
My experience was, that this NaN's only appear with
--prop:/sim/ai-traffic/enabled=1 on win32. All other things seems not to
produce NaN's.
Btw I wonder if we still need ai-traffic, as the interactive traffic works
so much
On Sun, Dec 13, 2009 at 10:16 AM, Stuart Buchanan
stuart_d_bucha...@yahoo.co.uk wrote:
A I recall, Torsten implemented that feature. There was a
description of it on the -dev list a couple of months back,
but I've been unable to locate it myself in the archive.
Here you go:
On Fri, Dec 11, 2009 at 7:00 PM, John Denker j...@av8n.com wrote:
Not too long ago, it was possible to print to stdout from
nasal scripts called from keyboard event handlers and joystick
axis handlers.
In the current (development) version, print() statements
have no effect chez moi.
Erik Hofman wrote:
Stuart Buchanan wrote:
Erik Hofman wrote:
I've been trying to pity up the sound dialog box without much success.
Is anyone with some more understanding of the gui configuration willing
to spent a few minutes on it?
I can take a look, unless Syd gets to it
John Denker wrote:
It's going to need testing. I'm seeing some peculiar
things, e.g.
http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-jfk-peculiar-taxiways
Just for the record: This is caused by a well-known and long-standing
'feature' in the 'genapts' utility, due to the fact that
Stuart Buchanan wrote:
I've just checked in an updated sound dialog with a tabulated layout.
Let me know what you think - I'm not sure whether the channel labels should
be left-aligned or right-aligned.
Very nice, it's about what I had hoped for. No need to change anything
if you'd ask me.
Hi All,
As John Denker pointed out, the FlightGear Short Reference was very out of date.
I've spent an hour or so making the key assignments accurate and improving the
mouse mode description. An updated version is available here:
http://www.nanjika.co.uk/flightgear/FGShortRef.pdf
Comments are
Hi All,
About this point in the release cycle, it's traditional to have a version
numbering discussion, if only so Martin and I can ensure that the documentation
matches the final binary!
My thoughts are as follows:
- The changes we've made in the last year are significant, so incrementing
Hi Stuart,
Stuart Buchanan wrote:
As John Denker pointed out, the FlightGear Short Reference was very
out of date.
I've spent an hour or so making the key assignments accurate and
improving the mouse mode description.
Good idea - I've been lost by far about what the current state of key
On 12/13/2009 02:33 AM, Erik Hofman wrote:
Jon, could you specify if this was with 'real' weather enabled or
disabled? I've seen something similar when it was enabled but haven't
seen it without real weather.
With an explicit --disable-real-weather-fetch, I still
observe an early FPE,
Stuart Buchanan wrote:
Erik Hofman wrote:
Stuart Buchanan wrote:
Erik Hofman wrote:
I've been trying to pity up the sound dialog box without much success.
Is anyone with some more understanding of the gui configuration willing
to spent a few minutes on it?
I can take a look, unless
Hi there,
The changes to fg in the past 12 months are very significant and welcome, but
the implementation of some of the changes is still in its infancy. That factor,
along with the missing shadows, leave me feeling that an update to v2.0 is not
yet warranted - not quite! Its getting close,
Traditionally it is MAJOR.MINOR.PATCHLEVEL, definately more than a
patchlevel thing, and way more than minor, so either 1.10.x or 2.x.x
if your following that standard. 1.10 feels weird, but not sure 2.x is
warranted just yet. Could ditch all that and use dates ala ubuntu,
making it what...like
On 13 Dec 2009, at 22:10, Jacob Burbach wrote:
Nan errors still abound, sound system has lots of rough edges still,
the new material system is not finished, route manager not finished,
etc, etc. Even if everything could be cleaned up by then, there would
be no time left for any real
Bug-fixing, testing, etc is of course a separate issue - namely that fixing
bugs is a lot less fun than writing features.
As a developer I certainly won't disagree with that, but they are an
absolute necessity for any software, it just comes with the territory.
As a user I would also say a
Jacob Burbach wrote:
Traditionally it is MAJOR.MINOR.PATCHLEVEL, definately more than a
patchlevel thing, and way more than minor, so either 1.10.x or 2.x.x
if your following that standard. 1.10 feels weird,
Maybe it is wierd.
1.9 is mathematically the same as 1.90
1.10 is less than 1.90 by
Hi there,
Whoever decided that software versioning should follow such a numbering
convention is a goozer, and you can quote me on that! :-)
There could have been any number of better ways to express the version number,
but they chose to use one that can combine more than one decimal place into
On Sun, 2009-12-13 at 19:07 -0800, S Andreason wrote:
Jacob Burbach wrote:
Traditionally it is MAJOR.MINOR.PATCHLEVEL, definately more than a
patchlevel thing, and way more than minor, so either 1.10.x or 2.x.x
if your following that standard. 1.10 feels weird,
Maybe it is wierd.
1.9
On Sun, Dec 13, 2009 at 10:48 PM, John Denker j...@av8n.com wrote:
...
UPDATE: I have a surprising explanation for the previously-
reported fact that FPE behavior depends on whether options
are passed on the command line or passed via .fgfsrc
It turns out that passing --enable-fpe via
Hi Stuart,
On Sunday 13 December 2009 10:16:24 pm Stuart Buchanan wrote:
A clear statement would
a) provide a good reference point for any further discussion outside of the
community, rather than various people making different comments.
b) be visible enough to Google so that anyone doing
27 matches
Mail list logo
