I'd like assent (lack of response will be taken as such!) to apply the
following tiny patch in main.cxx:
realtime-view-mgr.patch
Description: Binary data
Which changes FGViewMgr to be updated using the 'real' elapsed time,
instead of the simulation time (i.e dt argument to update()
On 2 Sep 2009, at 01:10, syd adams wrote:
I might be misunderstanding too , because Ive always been able to
pan the view with the mouse while paused ...
A good lesson in how different people use different interfaces to the
same functionality, and see different things :)
This patch does
Can someone familiar with the current state of the shaders/effects
code inform me if I'm what I'm seeing in the following shots is:
- intended
- a known, generic bug (or work in progress)
- an issue to specific to my setup that I need to supply more
information about
On 29 Aug 2009, at 14:24, Torsten Dreyer wrote:
Modified Files:
runways.cxx
Log Message:
missing declaration of SGPropertyNode
Cheers Torsten - really odd that it built fine for me.
James
--
Let Crystal
On 21 Aug 2009, at 10:55, Tatsuhiro Nishioka wrote:
I took a look at the code, and I believe I can implement the Mac
portion of the new input event model using HID Manager.
I'll post the patch when I finish implementing it.
I was 'responsible' (more like 'guilty') for some of the current
On 20 Aug 2009, at 14:08, Torsten Dreyer wrote:
Log Message:
warning fix: initializing members in the order they are declared
keeps gcc happy
Torsten, you are a good man!
Regards,
James
--
Let Crystal Reports
On 6 Aug 2009, at 23:07, Stuart Buchanan wrote:
While the current random forest code distributes the individual
trees evenly across the terrain. This works well for large areas of
forest, but less well for more mixed terrain, where individual
copses/woods of trees are mixed with
With latest CVS (source and data), I'm seeing the following
continuously in the console (with the UFO, obviously):
Instance of model Aircraft/ufo/Models/marker.ac has invalid values
CullVisitor::apply(Geode) detected NaN,
depth=nan, center=(0 0 35040),
matrix={
nan nan nan nan
On 24 Jun 2009, at 06:19, Mathias Froehlich wrote:
Log Message:
Provide a thread safe SGWeakPtr implementation.
Extend SGAtomic with atomic exchange and add.
Import updates from the original implementation of that in OpenFDM.
An observation: this change has stopped SGAtomic being (by
On 20 Jun 2009, at 14:42, Martin Spott wrote:
Yup - the DME element of an [ILS,VORTAC,VOR-DME,NDB-DME] is to be a
separate entity in the 'nav.dat' file by definition,
Okay, which leaves the other issue: ADF. Neither the generic adf.cxx
nor kr87.cxx search ILS stations. Looking at this PDF:
On 20 Jun 2009, at 12:12, Mathias Fröhlich wrote:
Better with that added spaces past the '\' ?
Sadly it made no difference - I already tried that fix locally.
James
--
Are you an open source citizen? Join us for the
Subject says it all - does anyone here know how to disable multi-line
comment warnings from gcc? Something like
-Wno-multiline-comment
except that doesn't seem to work for me. I've tried Google-ing, but
without success so far, and the GGC man pages don't mention such an
option
Doing some further work on the navaid loading/search code, I've come
across comments in adf.cxx search() and dme.cxx search() which raise a
question.
The comments (which look to have been copy-and-pasted, since there's
other comments which are identical in those functions) imply that both
On 20 Jun 2009, at 12:21, James Turner wrote:
The comments (which look to have been copy-and-pasted, since there's
other comments which are identical in those functions) imply that both
the ADF and the DME code should be searching the ILS list as well as
the combined VOR/NDB list. Obviously
On 16 Jun 2009, at 00:47, Jari Häkkinen wrote:
The reason for doing the above is that I do not like the macflightgear
strategy of having snapshot copies of different fg components in the
macflightgear repository. Also, getting access to all new stuff
takes a
while since the macflightgear
On 16 Jun 2009, at 12:04, Tim Moore wrote:
sg_location now uses C strings. Also, change uses of sg_throwable to
more
specific exceptions like sg_io_exception.
A bit of a tangent, but: I've used exceptions in the code I've
contributed, where I feel they are appropriate, but I've often
On 16 Jun 2009, at 13:32, Tatsuhiro Nishioka wrote:
I think it might be a problem on nVidia driver update that Apple
released after 10.5.6 update. I have an iMac with nVidia GT7300, and
it also has the same problem as James has.
This makes me really happy, since it means my specific system
On 14 Jun 2009, at 23:38, Jari Häkkinen wrote:
I am running fg on an MacBook Pro (10.5.7) equipped with an GeForce
8600M GT graphics card. I have not experienced any problems with
macflightgears 1.9.1 nor with the May 19 CVS package (my 1 hour flight
ended just a few minutes ago). I usually
On 14 Jun 2009, at 12:08, Frederic Bouvier wrote:
FGPavement::FGPavement(const std::string aIdent, const SGGeod
aPos) :
FGPositioned(TAXIWAY, aIdent, aPos, false)
Fred, are you sure we don't want to add a new FGPositioned::Type for
this? I don't mind either way, it's whatever you think
CVS seems to have developed a bad bug (since 1.9.1 based on some
testing) where on my nVidia-based Mac, the display server hangs
completely - I can ssh in and reboot the machine from the command
line, but there's no way to get the GUI back. The crashes occur after
a few minutes (sometimes
On 12 Jun 2009, at 09:54, Melchior FRANZ wrote:
And
I intend to make all widget properties live, so that one can,
for instance, change the x component (and optionally re-layout
the dialog), and see the widget move. It'll be nice to have live
color changes and to see the total weight text in
On 12 Jun 2009, at 10:04, Melchior FRANZ wrote:
I checked over the dialog code, and I don't see a standard 'visible'
or 'hidden' property (looking at FGDialog::makeObject), but perhaps
there is some other way to achieve this?
There's a visible property per widget group, which defaults to
On 12 Jun 2009, at 17:39, Tim Moore wrote:
So, I propose to add an argument to readProperties that controls
whether or not the new
property types are recognized. By default they are not, so only code
that explicitly calls
for them will be able to use them.
Seems entirely reasonable to
On 11 Jun 2009, at 09:52, Torsten Dreyer wrote:
Since this was a quite complex formula, nobody noticed. Now, it is
obvious
just by looking at the class names SGGeoc and SGGeod.
Another good reason for using SGGeoc and SGGeod, I think.
I will do some performance tests to see how much cpu
On 10 Jun 2009, at 21:29, Martin Spott wrote:
I'm not aware of such data within the FlightGear project, but I
think
project magenta has some in their navdata download section yet
I have no clue about their license and the scope of their collection.
If there's some available under a
On 10 Jun 2009, at 20:55, Torsten Dreyer wrote:
The ridge_lift is now also using the SGGeodesy methods, making the
code much
cleaner, too.
A word of caution - looking at the code, it seems like you're mixing
geocentric (SGGeoc) and geodetic (SGGeod) co-ordinates. I haven't
looked at
On 8 Jun 2009, at 23:12, Martin Spott wrote:
Actually the official FlightGear time matches the unix approach of
tracking seconds since the epoch.
Well, the scope on which James is focusing in his question is -
obviously - the property tree and so far I've been unable to spot a
place where
On 9 Jun 2009, at 17:12, Erik Hofman wrote:
At the end of the day, the correct approach really depends on
what you
are trying accomplish (what values and in what format are you
trying to
compute?)
Also, there is a difference between the value in the property tree
(which is just a
People tracking CVS will probably have noticed I'm pushing and pulling
SGWayPoint around in various ways, which is foundation work for some
route-manager changes. The major thing I've committed today, is
removed every use of temporary waypoints to run
SGWayPoint::CourseAndDistance, which
On 5 Jun 2009, at 19:52, James Turner wrote:
I want this for the route-manager dialog, but I can imagine similar
concepts being useful in the other places in the GUI - for example
the 'position on ground' dialog could have the runway and parking
position fields replaced with menus
Another of those simple-but-awkward questions:
Is there an accepted way to store an absolute time (as opposed to an
interval or delta) in the property tree? The obvious way (to me)
would seem to be using a double to store seconds since the Unix epoch,
but it's not exactly human-readable.
On 12 Mar 2009, at 06:21, Mathias Froehlich wrote:
Improove FGTileMgr::scenery_available for small ranges.
Use SGGeod in FGTileMgr, FGScenery apis.
Yay for SGGeod in APIs generally!
I've already screwed up several times passing lon/lat to routines that
that expected lat/lon.
James
On 7 Mar 2009, at 21:47, Mathias Froehlich wrote:
Modified Files:
SimGear.vcproj
Log Message:
Zap SGLocation.
Modified Files:
projects/VC7.1/SimGear.vcproj projects/VC8/SimGear.vcproj
simgear/scene/model/Makefile.am
simgear/scene/model/placement.cxx
On 7 Mar 2009, at 09:40, James Turner wrote:
start FlightGear using fgfs --aircraft=CitationX --airport=CYOW --
runway=25
take off, and make a left turn to heading 98, while maintaining an
IAS of approx 250 kts, and an altitude of approx 2500 ft. Maintain
this heading for approx 13 minutes
On 7 Mar 2009, at 09:12, Durk Talsma wrote:
Given that the actual error was preceded by the CullVisitor nan
message, I hope this crash situation might also give some insights
as what's going on there. Note that I am using some custom settings
in my local preferences, file, but I have no
On 22 Feb 2009, at 08:23, Frederic Bouvier wrote:
Modified Files:
positioned.cxx
Log Message:
Compile with VS2005 in debug mode
Thanks to everyone who's had problems with this for their patience,
and to the people who worked out and committed a fix. It's my code,
but I have no
On 17 Feb 2009, at 00:49, Curtis Olson wrote:
At one point I think I recall that we had a variant of the C172 with
a working GPS installed in the instrument panel. I don't see that
any more now. Does anyone recall if we had such a thing and know
where it can be found?
I presume
On 13 Feb 2009, at 09:23, Vivian Meazza wrote:
It compiles here under MSVC8, but I’m aware of at least one other
report of this problem. The current analysis is that if you compile
in release mode, it works OK, but the error appears in debug mode.
If you try that, I would be interested in
On 15 Jan 2009, at 15:23, Martin Spott wrote:
Commit Benoit Laniel's patch which converts more SimGear pieces to
use
OpenThreads primitives directly.
Woohoo, great - better late than never ;-)
I'm going to push through some other cleanup in the next few days, so
that the SimGear
On 13 Jan 2009, at 17:41, Csaba Halász wrote:
Somebody please commit this.
Done.
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
On 14 Jan 2009, at 11:16, Martin Spott wrote:
As far as I know - there's no diference between solid and liquid
surfaces
from FG/SG point of view. In other words
- rivers, lakes, ocean are a part of TerraGear scenery (except
OceanTiles
for non existent BTG-s of course).
Right, in the
On 14 Jan 2009, at 15:13, Rob Shearman, Jr. wrote:
Lately I have noticed that the glideslopes seem to be uniformly
wrong or inoperable somehow. This changed within the last couple of
builds. Previously, when on final, the visual glideslope indicators
would essentially match up with what
On 14 Jan 2009, at 16:00, Curtis Olson wrote:
My sense is that there are many areas in the world where the slope
of the shore line is very shallow. Also don't forget that our SRTM
data has a resolution / random noise element of about +/- 5 to 10
meters. I think that these things
On 14 Jan 2009, at 19:40, Martin Spott wrote:
To my understanding of your posting you're implying that someone would
like to move the shoreline around. Indeed, if we would derive the
coastline entirely from the SRTM elevation, then we theoretically
_might_ run into trouble, but nobody's
On 14 Jan 2009, at 20:13, syd adams wrote:
This might be partly my fault , I changed the neelde animation
because it was pointed out that it was too insensitive , but now it
has a very narrow window to operate in , and the ealier discussions
and the manual don't jive so I'll look
On 14 Jan 2009, at 23:31, Tim Moore wrote:
There has been a flurry of bug fixes in the last few days. I want to
review the
state of the maint branches in the simgear and flightgear git
repositories and
suggest that they would now be a good source for a 1.9.1 bug fix
release. I've
On 14 Jan 2009, at 23:40, Csaba Halász wrote:
There are some pending NaN problems I have reported, but have not
been fixed.
And users are complaining about IntersectionVisitor/CullVisitor
flooding console with messages about NaNs ;)
Between Fred, Tim and myself, I thought we'd committed
On 14 Jan 2009, at 23:56, gerard robin wrote:
AND what about clouds with blue_edge ?
http://pagesperso-orange.fr/GRTux/3DClouds-blue_edge.jpg
I'd say, not worth delaying 1.9.1 for - unless there is a low-risk
fix, which I doubt, since it appears to be a sorting issue. 'Clouds
look a
On 12 Jan 2009, at 11:19, Frederic Bouvier wrote:
It also seems that large framerate ( more than 200 fps during
splashscreen display, I even saw 600 at FSFO ) make the scenery load
a bit longer. Curiouly, I see better loading time under Linux with
an AMD Athlon XP 2400 and a NV FX5850,
On 11 Jan 2009, at 20:07, Tim Moore wrote:
I propose that the 1.9.1 release be made from these maint
branches. This would
let progress continue in CVS while hopefully achieving some
stability in a
maintenance release. If current committers would like write access
to these
repos, let
On 11 Jan 2009, at 17:18, Frederic Bouvier wrote:
My findings on that is that the pager thread needs to compile display
list in the main loop, and this process is framerate dependent. At
that
time of the initialisation, there is only the splashscreen on screen,
but its refresh rate slow
On 9 Jan 2009, at 10:42, Torsten Dreyer wrote:
with cvs as of today, I receive a segfault shortly after starting
fgfs;
No command line args, no .fgfsrc, no .fgfs directory, standard
preferences.xml
fresh autogen.sh and configure
Almost certainly my fault - do you known when you last
On 9 Jan 2009, at 13:18, gerard robin wrote:
get same kind of crash here with gdb:
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x0088c7c9 in
FGAirport::getIteratorForRunwayIdent(std::string const)
const ()
Current
On 7 Jan 2009, at 19:05, Tim Moore wrote:
I like to fetch and then rebase my local work without merging; it
makes
it much easier to get the commits into CVS via git-cvsexportcommit.
When we move
to git and publish (sometimes) personal branches, I'll probably
switch back to
git-pull.
On 27 Dec 2008, at 15:04, Tim Moore wrote:
Here's my workflow for using git with the FlightGear sources in CVS.
Note that
there are separate repositories for Fightgear, Simgear and the
Flightgear data.
This is inconvenient and there may a workaround using git
submodules, but I
On 3 Jan 2009, at 13:17, Roy Vegard Ovesen wrote:
Please apply this patch to extract the hours minutes and seconds
without using
silly while loops.
Thanks (and I will apply this!), but to re-iterate, I have a re-write
of the entire GPS code pending - but I'm holding off committing until
On 2 Jan 2009, at 22:28, Alex Perry wrote:
No. The standard design is based around 3 degrees slope. With that
design, the usable range is 1.4 degrees high, from 2.1 to 3.7 degrees
and offers 0.35 degrees per dot. Therefore, a dot equals 50ft per
mile range from the touchdown zone of the
On 3 Jan 2009, at 15:04, John Denker wrote:
On 01/03/2009 06:58 AM, James Turner wrote:
- everyone seems agreed that the GS is a 1.4 degree volume, so 0.7
degrees above and below the GS line.
I concur.
Please let's not confuse ICAO (which is quite general) with
Mk-VIII (which is just
On 3 Jan 2009, at 16:17, John Denker wrote:
They don't care what local units are used to communicate
between the tuner and the CDI head. It could be gallons
as Torsten mentioned.
The existing code uses [0 ± 10] gallons for the left/right
needle and [0 ± 3.5] gallons for the up/down needle.
On 3 Jan 2009, at 17:12, John Denker wrote:
Is there anything unrealistic about item (B)? Is there
any instrument/system in the world that expects the
nav tuner to put out the GS angle in degrees?
The only MK-VIII known to me is a GPWS, and I very much
doubt it needs to know any GS info
On 3 Jan 2009, at 17:38, John Denker wrote:
A) We are now agreed that deflection as a fraction
of full scale is a supported feature, not deprecated,
not scheduled to rot, right?
Err, I would say that we don't have that as a current feature, but I
think that's getting into semantics of
On 3 Jan 2009, at 18:10, Csaba Halász wrote:
But you credited it to the wrong person ...
Ooops, yes.
Apologies to Roy and Ron for the confusion.
(I could make a poor excuse about names that start 'Ro-' and end with
'-sen', but I think I'd be laughed at)
James
On 3 Jan 2009, at 18:47, Roy Vegard Ovesen wrote:
marginally less silly ;-)
IMHO this is the most elegant code I've submitted in a lng time,
but if
it's only marginally less silly, then perhaps I don't mind not
getting credit
for it. :-D
Heh :)
Roy, your code is fine, it's the
On 2 Jan 2009, at 09:05, Torsten Dreyer wrote:
Nothing is wrong with this approach, but the normalized, dimensionless
approach is a more general one.
Not really my area of expertise, but I'd far prefer to use real volts,
and have the aircraft electrical system define globally what it
On 2 Jan 2009, at 05:59, John Denker wrote:
On 01/01/2009 10:05 PM, syd adams wrote:
I think i assumed long ago that the GS deflection had a limit of
-10 to 10
like the heading-needle-deflection , and so scaled the needle to the
outermost dot accordingly.
That is not consistent with
On 2 Jan 2009, at 11:58, James Turner wrote:
Not really my area of expertise, but I'd far prefer to use real volts,
and have the aircraft electrical system define globally what it
considers nominal to be to, i.e what John proposed with:
Whoops, re-reading this, a tiny addendum: while I
On 2 Jan 2009, at 04:20, Csaba Halász wrote:
Found the feenableexcept() function, so expect more of these :)
Thanks to Ron for his help.
Applied. Frankly, all uses of atan() should probably be replaced with
atan2(), but with some inspection of the call site to verify the
change is sane.
On 2 Jan 2009, at 12:57, John Denker wrote:
The only thing that the jumper approach really needs is for
you to set a jumper to tell other people what you have done.
Asking aircraft designers to set one or two jumpers in the
property tree doesn't seem unreasonably burdensome.
This is the
On 2 Jan 2009, at 13:26, Anders Gidenstam wrote:
Could we find more descriptive property names for these voltage/
potential
difference properties? Just to make it clear what they are (and avoid
confusion with potential future properties, e.g. for current, charge
or
power).
Good point.
On 2 Jan 2009, at 13:50, Curtis Olson wrote:
However, the existing XML based electrical system model is extremely
difficult to use from an xml configuration standpoint, and although
it worked ok for the c172 electrical system, I began to run into
core design barriers when i was
On 2 Jan 2009, at 17:32, Csaba Halász wrote:
Not sure what it is calculating anyway. This happened with the
hurricane just at startup.
And all the while loops look silly too. Not to mention that it
should probably display times up to 99:59:59 so the check at the top
is wrong.
I have a
On 1 Jan 2009, at 16:40, Tim Moore wrote:
I may have been confused about what James proposed to commit. My
understanding
is that Yon's patch mostly makes the other one obsolete, but that
there also
seems to be some instability in it. In any case, a 1.9.1 should have
a minimum
of bug
On 31 Dec 2008, at 10:50, Vivian Meazza wrote:
On the other hand, there has been a recent and significant
improvement in
frame rate. I'm not sure if it's Yon's, Tim's or James' stuff, but
well done
all.
I'd love to take credit, but I don't *think* it can be me - I've made
some
On 31 Dec 2008, at 10:11, Frederic Bouvier wrote:
An early 1.9.1 ?
I think we need to get a handle on the 'scenery loading takes 2
minutes' issue before doing a 1.9.1
Completely wild guess - hitting a slow path in OSG or the driver due
to some missing feature / unsupported extension?
On 31 Dec 2008, at 11:28, Yon Uriarte wrote:
I havent cvs updated in a few days, but merging both
the use OpenThreads atomic and use display lists for
shader trees would benefit win32 users and general fps.
I'll see if I can merge soon and repost a patch.
I've tested both locally, and
(sorry for the long email, but please read if you are involved with
panel creation, or can shed light on nav-radios)
I have had an entertaining afternoon, and now morning, with the Mk-VIII.
Along the way, I believe I have discovered some genuine bugs in the
code, and some odd assumptions
On 31 Dec 2008, at 13:09, James Turner wrote:
...as giving a value of 0.32 degrees GS deviation per dot. I'd love to
know if this is correct, and what the VOR/HSI deviation is (in degrees
per dot) (I believe the 'LOC is 4x the sensitivity of VOR' rule is
indeed correct, but again, please
Here's the patch again:
referenced.patch
Description: Binary data
We don't really want to becommittingpatches that add #ifdef control variables - if everyone agrees the OpenThreads primitives are the way to go, we should switch permanently, not support both. But in the short term it's a good way
On 31 Dec 2008, at 17:38, Martin Spott wrote:
Now that the release is out, my I add a little reminder to this patch
which was meant to add some 'cleanup' to SimGear's use of threading
libraries:
http://blaniel.free.fr/pub/flightgear/patches/ot_simgear.patch
That patch is entirely
On 31 Dec 2008, at 19:32, Martin Spott wrote:
Do/merge/leave whatever/however you like, I just wanted to make sure
Daniel's changes don't get lost.
Right, thanks for clarifying. I'm happy to apply the still-relevant
parts of this, and Yon's SGReferenced patch, but I want a positive
On 30 Dec 2008, at 09:51, Alasdair Campbell wrote:
Looking initially at the atis.cxx, ATCmgr.cxx, etc code I notice a
bunch
of commented-out cout statements, which give me a good idea of where
to look for solutions. I wonder if there is a case for introducing
a -v
(--verbose) option
On 30 Dec 2008, at 11:03, Frederic Bouvier wrote:
Modified Files:
dynamicloader.cxx
Log Message:
Win32 fixes
Thanks Fred.
--
___
Flightgear-devel mailing list
I've just had a lockup while landing (with a tuned GS) in the Bravo,
due to a Mk-VIII glitch. It's getting stuck in a loop around about
Mode5Handler::update_soft/get_soft_bias/is_soft, with either some
uninitialised values or memory corruption.
It's possible this is a local problem to my
On 28 Dec 2008, at 23:05, John Denker wrote:
Here's the patch to make the new pick animation behave more
like the good old 2D panel. This makes it possible to turn
on the repeatable feature in 3D without quite so many bobbles.
--- a/simgear/scene/model/animation.cxx
+++
On 28 Dec 2008, at 19:50, Vivian Meazza wrote:
I generally make 3d panels, but I find textranslate etc useful,
indeed vital
within these 3d instruments for example in HIS.
I'm also using them for rain effects on canopies, so as far as I'm
concerned
the 2d panel stuff is still very
On 28 Dec 2008, at 20:27, sydad...@telus.net wrote:
I'm aslo in favor of keeping and upgrading the 2d panel system. It
would be nice to have a 2d line drawing layer also.
Yes, that seems to be second most common request after text. I'm still
debating that one, because while I can see it
(I essentially agree with everything Tim, but want to add one
technical detail)
On 29 Dec 2008, at 13:12, Tim Moore wrote:
Putting snark
aside, I'd suggest that FG is not in as bad shape as you think. The
property
system is already a great mechanism for communication among the sub-
On 29 Dec 2008, at 08:40, Tim Moore wrote:
.4 meters seemed
sufficient to me, but others don't agree, so perhaps we can settle
on some value
larger than .1. The near plane value is settable, both in the camera
configuration and as a live property in /sim/rendering/camera-
group/znear.
I'm planning to create some slightly advanced cockpit instruments in
the near future, and to do this I need to support some more complex
text displays. (This is for the character-based displays on the
KLN89/94/etc GPSs, and FMS/MCDU units in the longer term).
I was intending to create some
On 28 Dec 2008, at 15:48, Curtis Olson wrote:
In my opinion, the 2d instruments are still very useful for people
that are setting up full screen panels as part of a larger simulator
where the out-the-window view is drawn on separate monitors and the
there may be one or more displays
On 28 Dec 2008, at 15:54, Heiko Schulz wrote:
Currently there are two approaches:
-making it all 3d. Means that signs, symbols lines are mostly done
with 3d-objects. Good example the 787-display
-using 2d-layers. Syd is using this approach on his 777 but it does
have problems on some
On 28 Dec 2008, at 16:12, Tim Moore wrote:
You should also take a look at the weather radar code in
Instrumentation/od_gauge.cxx and wxradar.cxx for yet another
appproach.
I'm familiar with that code (it's how I built my current Nav Display
prototype) but I'm not 100% happy with the
On 27 Dec 2008, at 09:39, Durk Talsma wrote:
On Saturday 27 December 2008 10:11:46 Stuart Buchanan wrote:
I think it's something we need to bear in mind for the next
release. We'll
need to put more effort to get external testing of RCs on Windows/
ATI.
Yes, I agree, but the problem is
On 27 Dec 2008, at 10:19, Tim Moore wrote:
Correctness, in the sense that I can't compile SimGear without this
change. Also
consistency, since in SimGear we consistently refer to headers from
other
SimGear modules using #include simgear/ The important part of
the change
is
On 27 Dec 2008, at 11:21, Vivian Meazza wrote:
Hmmm, neither version compiles here with MSVC9. Gives the following
error:
source\simgear\math\SGMisc.hxx(27) : error C2059: syntax error :
'L_TYPE_raw'
followed by hundreds of errors like this:
On 26 Dec 2008, at 16:37, Timothy Moore wrote:
I recommend that you use git-cvsimport -k. It can be a bit time-
consuming, but
I've never had the kind of inconsistencies that I would see with
taylor, and
it knows how to do deletes!
I could benefit from some advice on using git to track
I'm noticing quite a few people on the forums with difficulty running
1.9.0 - either long delays on startup, hangs while loading scenery,
crashes or rendering issues. Some of these are certainly driver
issues, especially with ATI and the dreaded Intel chipsets. And of
course people who're
On 25 Dec 2008, at 18:38, Tatsuhiro Nishioka wrote:
1) The version numbers and release dates
Here's an example list of version numbers and release dates when
FlightGear will be released quarterly.
2.0 - at the end of March, 2009
2.1 - at the end of June, 2009
2.2 - at the end of
On 25 Dec 2008, at 10:54, John Denker wrote:
52:: Core feature: Nav: Reversible ILS: Consider the following
scenario. In the 1.9.0 Sim World, you are on the KJFK ILS RWY 31R
snip
In the Real World, the active runway is determined based on wind
conditions (etc.) and the reversible ILS is
On 25 Dec 2008, at 22:46, Stuart Buchanan wrote:
As far as I am aware, none of those documents is up to date, or
reflects current
development.
Yep - that's partly why I created a personal 'plan' page - so I can
say what I *am* working on, and what I intend to work on, and hence
901 - 1000 of 1199 matches
Mail list logo
