On 7 Mar 2006, at 14:49, Erik Hofman wrote:I got an answer from someone who has been working on getting the RenderTexture class working for Mac OS-X. Who is the main OS-X developer who wants to test this code and make some adjustments if necessary? Hmm, I've done some work on this over the past
On 8 Mar 2006, at 16:28, Melchior FRANZ wrote:I've today added Nasal support for XML dialog files. Each dialog can have a nasal block with open and/or close element. Nasal code therein is executed on dialog opening and closing. This code and all Nasal code in the dialog bindings run in the same
Possibly this is just me, but: I find adding pilot models to the aircraft a bit weird - could it be made optional (a submodel)? I can't quite explain why, it just seems disconcerting to me. Of course there is an argument for having models for each crew member and passenger, to accurately reflect
On 27 Mar 2006, at 17:48, David Megginson wrote:That's exactly it. I fly to CYTZ frequently in real life, and I can attest that the runways are only a few feet above lake level (I actually flare over the water sometimes before touching down on runway 26, so that I can land short and make the
On 28 Mar 2006, at 04:05, syd sandy wrote:Hi Steve , the Citation -II or Bravo ? Im just about ready to send another Bravo update , with a bunch of FlightDirector / Autopilot fixes. I havent done anything with the Citation II in quite a while , but I should be able to incorporate the Bravo
On 3 Apr 2006, at 09:26, Ralf Gerlich wrote:thinking more about the issue and trying to get some distance to the "whohoo!"-attitude of some of the CLOD-papers I read in the last weeks, I'm more and more coming back to the conclusion "simple is beautiful". Perhaps we'd be best off slicing our
I've just done a first stab of a binary release for OS-X, based on CVS as of yesterday. If you have access to a Mac with either 10.4.x or 10.3.9, please test it:http://homepage.mac.com/zakalawe/.Public/flightgear-0.9.10-pre-osx.dmgThings to keep in mind: - there is no data dir inside the bundle,
On 5 Apr 2006, at 00:15, James Turner wrote:I've just done a first stab of a binary release for OS-X, based on CVS as of yesterday. If you have access to a Mac with either 10.4.x or 10.3.9, please test it:http://homepage.mac.com/zakalawe/.Public/flightgear-0.9.10-pre-osx.dmgThings to keep in mind
I'm trying to compile FlightGear 0.9.10-pre3 on my PowerBook, but the installation of simgear fails while "make" with following error messages: if g++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/FlightGear/include -g -O2 -D_REENTRANT -MT visual_enviro.o -MD -MP -MF
On 8 Apr 2006, at 23:44, Pigeon wrote:It's possible to disable the UIUC and other esoteric FDMs entirely at the configure stage, IIRC. I looked at FG's configure briefly and I do not see how. Anyway, here's a patch attempting to "new" AIRCRAFT only when it's needed. A brief test
On 10 Apr 2006, at 12:01, Steve Hosgood wrote:What's the fix? Insist on only a certain version of Freeglut? In my local build on FC5, I just switched to SDL. And yes, I hit this issue as well, and was thoroughly confused by it. Perhaps configure should AC_WARN loudly when it detects freeglut? (or
On 11 Apr 2006, at 21:56, Curtis L. Olson wrote:Has any one produced a MacOS package of FlightGear-v0.9.10? I produced a 'pre' binary which seemed to work ok for those who tried it, and worked for me on both 10.3.9 and 10.4.x. It has no GUI, unlike Arthur's 0.9.9 release, because I don't really
On 14 Apr 2006, at 20:11, Curtis L. Olson wrote:I just received email from Auther Wiebe that he is no longer able to maintain the MacOS build. I've had a few people ask about the status of a MacOS version of v0.9.10 and so far I've only been able to relay bad news. Is there anyone out there that
On 15 Apr 2006, at 00:43, James Turner wrote:I'll do the 0.9.10 build tomorrow, first thing (promise!) As for it being official, well, now I have the X-Code projects sorted, actually doing the build is straight-forward, almost automatic. If I had an account on an 'always on' Mac, it would be easy
On 16 Apr 2006, at 13:31, Jim Wilson wrote:It is downloading now to try it. Can we put the file on sf.net? I'm willing upload the file if that helps. My sf login is spiderbarker. If uploading to SF was the issue, I could do it myself; but it needs an admin on the FG project to push it up. If
On 16 Apr 2006, at 15:54, Jim Wilson wrote:It's working well on my g4 notebook. What is the issue with Arthur's wx interface? Is there anything I can do to help with getting that back into the package? The issue would be, I don't like wxWindows :)I have a cunning plan for achieving the same GUI
I'm plotting to add support for startup GUIs in FlightGear itself, spurred on by recent issues with Mac GUI. My approach is to twiddle the order of initialisation so that at a critical point during the idle_state progression, the NewGUI subsystem is up, config options have been parsed, and the nav
On 18 Apr 2006, at 08:56, Erik Hofman wrote:I'm plotting to add support for startup GUIs in FlightGear itself, spurred on by recent issues with Mac GUI. My approach is to twiddle the order of initialisation so that at a critical point during the idle_state progression, the NewGUI subsystem is up,
On 18 Apr 2006, at 10:07, Melchior FRANZ wrote:As you know, the reason for Nasal being the last of the subsystems is that it processes the files in $FG_ROOT/Nasal/ on initialization. And the idea was that these scripts should find all subsystems initialized, so that they can access some generated
On 18 Apr 2006, at 10:31, Melchior FRANZ wrote:Umm ... but what if it wants to wait for more than one subsystem. While possible, that would quickly become disgusting. Better real Nasal dependency resolution then. :-| I think adding more groups and keying off them is much easier - I don't have any
On 18 Apr 2006, at 11:36, Melchior FRANZ wrote:I think adding more groups and keying off them is much easier Sure. This wasn't meant as argument against your sublevel idea. (In my code I had added Nasal to the INIT group weeks ago, because this could have solved an exit problem that I had at
On 18 Apr 2006, at 11:53, Melchior FRANZ wrote:Umm, no. The "end part"?! This should be OK then. But it gets more and more fragile because of such manually resolved dependencies. Agreed - hence this discussion. Otherwise we'll end up with postpostpostinit(), or as I like to call it, 'run level 4'
On 18 Apr 2006, at 00:51, Adam Dershowitz wrote:
I just tried to build simgear from CVS and got a similar, but not
identical error to the above:
g++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/Users/dersh/
Programming/FlightGear/include -g -O2 -D_REENTRANT -c -o
visual_enviro.o
On 22 Apr 2006, at 00:14, Curtis L. Olson wrote:Arthur emailed me that he would try to get a v0.9.10 build out the door, but I don't have any current status or ETA. I think the lesson here is that we really could use a more active and larger Mac developer contribution to the FlightGear project.
On 28 Apr 2006, at 14:13, Savaş Yatmaz wrote:I saw and tested the autobrake functionality on 737-300,and it works well.I can set it with http server or internal property editor.Is there a plan to assign a keyboard shortcut to it? Nasal func :
On 7 Jul 2006, at 11:38, Erik Hofman wrote:I'm not sure, according to Alexander it should work (although is hasn't been able to test it in FlightGear itself) but others have reported problems. Nobody, however, has picked up the task to fix it properly. I'm confused by this; both myself and
(Trying to get back up to speed with FG after a few years absence)
I've noticed the FG (and SG) code contain a fair amount of legacy pre-
processor cruft, some of which is already accompanied by (sometimes
hilarious) comments questioning its validity.
Notably:
- #defines relating to
On 25 Jul 2008, at 01:07, Erik Hofman wrote:
I've just recently committed a patched version of JSBSim that did just
that and so far I've seen nobody complaining.
For me it's a rather simple issue; FlightGear 1.0 is the last version
for old(ish) hardware and compilers and FlightGear CVS is
On 24 Jul 2008, at 19:43, James Turner wrote:
I'll work on some patches for the macintosh | __MWERKS__ | __APPLE__
stuff, FX / XMESA stuff is not controversial, but I'd want to avoid
creating merges headaches for people working on OSG code. I guess
cleaning up / getting rid of compilers.h
On 24 Jul 2008, at 20:36, Tim Moore wrote:
I'm all for cleaning up the #ifdefs and #defines. As a baseline, we
don't need
to support compilers that are too broken to compile OpenSceneGraph,
and we would
like to support Cygwin. I believe that gives an oldest gcc version
of 3.4.4.
Some Mac / __APPLE___ cleanups for someone to (hopefully) commit:
- remove the OSX_BUNDLE crap *I* introduced years ago - we're always
a a bundle on Mac now.
- fix up the default fg-root on Mac to be FlightGear.app/Contents/
Resources/data - i.e the location used by the macflightgear.org
(mostly for Fred, I guess)
Whilst cleaning up various headers and includes, I've noticed quite a
few files including windows.h, via a section like:
#ifdef HAVE_WINDOWS_H
# include windows.h
#endif
Many of these files have no obvious reason to be relying on platform
specific code, and I
On 27 Jul 2008, at 16:41, Frederic Bouvier wrote:
you have no idea about the cruft windows.h is dragging.
True. But I had the impression that you were adding the
#if ... #include windows.h #endif to every single file,
anyway. :-)
You are misinformed. I was adding config.h. Look at the
On 27 Jul 2008, at 17:24, Durk Talsma wrote:
You might be interested in some work done by Thomas Foerster. Thomas
has done
a fairly detailed analysis of the current interdependencies in
FlightGear's
include files. IIRC, Thomas has a patched version of FlightGear that
already
removes
On 27 Jul 2008, at 21:02, Tim Moore wrote:
If you're doing that work, I'd like you to follow a *really*
minimalist stance
i.e., if a header file only contains pointers or references to
another class or
includes them as arguments in uninstantiated templates (e.g.,
osg::ref_ptrfoo), then
On 28 Jul 2008, at 02:39, Tim Moore wrote:
I'm not sure what's going on in your example, as foo needs to be
defined
somewhere in order for wibble to inherit from it. Otherwise there's
serious bug
there.
If we're requiring a never MSVC than that, I believe we're fine. And
perhaps you
(here's a can of worms, please forgive any erroneous assumptions I'm
making)
As someone new coming to FG, it's pretty tricky to get a handle on
what's going on, what's being worked on, what needs fixed and so on.
Of course this is an issue for all software projects, and there's
different
On 29 Jul 2008, at 20:41, Tatsuhiro Nishioka wrote:
I applied your patches and it seems working properly so far on my
environment (cvs/osg as of several days back). However, I needed the
following additional patch for avoiding compilation errors.
Anyway, could someone apply his (and my)
On 30 Jul 2008, at 11:29, Erik Hofman wrote:
To continue this discussion a bit (please add your comments) James
an I
had a short discussion about using std::string (for example)
everywhere
in the file or using using std::string; at the beginning. James
pointed out that the suing std::
On 30 Jul 2008, at 13:23, Melchior FRANZ wrote:
Actually, I think that putting std:: at every reference is
not preferable, as in 99% of the cases we mean std::string,
and in 100% we mean std::cout, so the prefix is basically
redundant noise. Do we actually have more than one or two
cases
After some playing around, the area of FG that I'd most like to see
improved, and therefore inclined to work on, is better glass cockpit
displays, and the systems behind them. I'm still reading over the
code, and looking at different aircraft to get a handle on this (and,
err, how
On 3 Aug 2008, at 20:22, R. van Steenbergen wrote:
The only issue I'm currently facing is how to integrate my current
work
into the already estabilished FG code. I'm a good OpenGL and C++
coder,
but I'm new to the FG code structure. It would be nice if someone were
to give me a
On 3 Aug 2008, at 19:58, SydSandy wrote:
I look forward to a better glass cockpit system. I did the Primus
1000 glass cockpits for the Citation's and 777-200 .
I am experimenting with the G1000 with moving map (with pre-rendered
Atlas images),but with nasal code.
Ive tried different
On 4 Aug 2008, at 10:43, Tim Moore wrote:
Lots of interesting issues here.
Yep :)
Instrumentation/wxradar.cxx and Instrumentation/od_gauge.cxx are the
existing
examples we have of a custom glass instrument. The weather radar
does work in
FlightGear OSG; there isn't any weather yet,
On 4 Aug 2008, at 07:28, R. van Steenbergen wrote:
I fear, though, that in some way you are going to have to fall back to
the rendering of very basic geometry (points, lines, rectangles)
because
they are the basic make-up of a 2D vector display.
I'm not clear what there is to be afraid of
On 4 Aug 2008, at 10:54, Frederic Bouvier wrote:
There is a new OSG pluggin that requires librsvg in OSG 2.6.0 RC1.
I didn't managed to build it under Windows though.
Depending on something like librsvg is pretty much my idea of hell.
It's heavy, depends on libart (or possibly cairo, now),
On 9 Aug 2008, at 15:32, Stuart Buchanan wrote:
I did consider it, but given the problems I've had simply trying to
port the existing code, I felt it was too much of a challenge for
the moment.
Seems like a classic thing to investigate (along with about a hundred
other potential
On 14 Aug 2008, at 15:50, Jon Stockill wrote:
I've just been setting up a new machine and I've been building all the
flightgear prerequisites from freshly downloaded source, but ran
into a
problem when it came to tracking down ALUT, so I thought I'd save
anyone
else from repeating the
On 14 Aug 2008, at 16:20, Anders Gidenstam wrote:
On my system I lost the doppler effect in fly-by view after I
updated to
that OpenAL. Has anyone else seen (or heard :) anything similar?
Doppler support in the code was a bit fiddly when I looked at it - due
to different implementation
Durk's kindly committed my runway refactoring - just to say, this was
a slightly far-reaching change, but a very beneficial one, I hope.
There's a few 'interesting' changes to come - I (or Durk) will be
taking advantage of the new 'getActiveRunway' accessor on FGAirport,
and Durk's runway
I encountered the following code, in the middle of
FGNavList::findNavFromList:
==
// LOC, ILS, GS, and DME antenna's could potentially be
// installed at the opposite end of the runway. So it's not
// enough to
On 15 Aug 2008, at 23:07, John Denker wrote:
Possibly constructive suggestions:
1) In the case of paired transmitters, turn on the one that serves
the
runway _favored by the wind_. Do this regardless of the location of
the aircraft.
Remark: This works even in multiplayer
I'm planning to do a slightly intensive re-factoring - creating a base
class where one didn't exist before. The (draft) base class is
attached - it will become a base for the following:
FGAirport
FGRunway
FGFix
FGNavRecord
ATCData
The members are
On 16 Aug 2008, at 09:50, Thomas Förster wrote:
while I'm pretty much in favour of spatial indices, note that a lot
of work in
that direction has been done already. As far as I know, Mathias
Fröhlich has
written a general templated spatial index for simgear. I've the code
with me,
On 16 Aug 2008, at 11:37, Melchior FRANZ wrote:
ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/SGHTMMap-20060223/SGHTMMap-first-take.diff
Mathias will know more about it. :-)
Gave this a quick eyeball and it seems pretty nice - and
straightforward to integrate with my proposed base
Attached patch refactors the KLN89 code to use the same navaid / fix /
airport storage as the rest of FG - instead of copying each (large)
list when the instrument is initialised. This gets rids of the
_waypoints member of DCLGPS - the waypoint class is still used in the
internal
On 17 Aug 2008, at 16:44, James Turner wrote:
Well, there's a motive here: because I'm using consecutive numbers for
the types, I can implement things like 'all airports' or 'all ATC
frequencies' as range compares, by doing lower_bound and upper_bound
queries against appropriate sets
On 17 Aug 2008, at 17:22, Martin Spott wrote:
I know some others use the GIT repo at:
http://mapserver.flightgear.org/git/gitweb.pl
as a reference. Maybe now it's the right time to unify on one single
repository,
I'm using git quite happily, it's working well as a way of tracking my
On 17 Aug 2008, at 18:53, John Denker wrote:
Yes, I'm sure there are plenty of people out there who are in the
habit
of shooting approaches without properly IDENTing the navaids. This
is a
common student mistake. Such people ought to thank us for
providing a
simulation that
On 18 Aug 2008, at 17:19, James Turner wrote:
This is in Dave Luff's ATC code - I'll take a look (probably tomorrow)
and hopefully make it more tolerant. I am curious what you did to
trigger the crash, though - most places validate the airport ident, so
I'd like to know where you're passing
On 18 Aug 2008, at 17:24, gerard robin wrote:
Only the luck :) , during development when testing an Aircraft
flying over
Mediterranean Sea , don't ask me to do it again, it is like winning
Loto
Interesting - I wonder if there's a typo in a data file somewhere.
'LExx' idents would
On 19 Aug 2008, at 08:15, Erik Hofman wrote:
I just checked and both the led font and lcd font are already
available
indeed.
Here is an image showing the Data Entry Display in action:
http://home.telfort.nl/sp004798/emh/ded.jpg
Side note - this is interesting, I'm still musing on the best
On 16 Aug 2008, at 03:10, James Turner wrote:
I'm planning to do a slightly intensive re-factoring - creating a
base class where one didn't exist before. The (draft) base class is
attached - it will become a base for the following:
I'd quite like to move forwards on this tonight, but I'd
I've been working on my FGPositioned ideas in a local git tree, to get
a feel for the scale of the changes. One thing I did last night was
the slightly painful conversion of FGRunway to be heap, instead of
stack based.
One interesting thing I've come across is how the runway _length and
On 20 Aug 2008, at 21:14, Frederic Bouvier wrote:
Migrating from CVS to SVN would already be a very good thing IMO
Just to add some data to this
- git works great on the Mac, or any Unix, but I believe it's never
going to fly (if you'll pardon the expression) on Windows, due to
On 21 Aug 2008, at 13:25, Erik Hofman wrote:
I'm working on proper Listener positioning for sound playback in
FlightGear and encountered a difference between the coordinate system
described in README.xmlsound (which describes a right handed system
that
doesn't exists, it describes a left
On 21 Aug 2008, at 13:33, Erik Hofman wrote:
I knew it! :)
Ok, I' l take a look at that, good idea.
One of the things on my medium-term list is to carry on the subsystem-
ification work. To reach the ultimate goal (mainloop just does
'update' on the subsystemgr) will take a long time, but
On 21 Aug 2008, at 15:26, Erik Hofman wrote:
+ FGViewer *current_view = globals-get_current_view();
+
+ // get the orientation
+ const SGQuatd view_or = current_view-getViewOrientation();
+ SGQuatd surf_or = SGQuatd::fromLonLatDeg(
+ current_view-getLongitude_deg(),
On 21 Aug 2008, at 15:31, Erik Hofman wrote:
This is now committed for the SGSoundMgr code, it has been moved tot
FGFX.
Just in case you care, my longer term plan for the sound code was to
create an SGSoundSource (in the simgear code), which would basically
be a wrapper around an OpenAL
On 21 Aug 2008, at 17:02, Anders Gidenstam wrote:
Why not trigger multiplayer sounds via property changes (in the same
way
as most of the other sounds are handled)?
Switching to only sending properties when they change would make it
feasible to have a bunch of MP enabled properties for
On 21 Aug 2008, at 16:46, Curtis Olson wrote:
I was able to find a set of options to the cvs2svn tool that worked
for our repository. The FlightGear repository takes about an hour
and 45 minutes to convert. So that part works well.
Yep, that's really great news - I have heard some
On 21 Aug 2008, at 17:50, Erik Hofman wrote:
But .. it might well be in this case.
No, I'm not sure either, it was just a gut feeling that depending on
FGViewer was a bit weird, for sound code.
Anyhow, cleaning up the main loop was the first priority for me.
Yep, agreed.
On 22 Aug 2008, at 18:01, Alasdair Campbell wrote:
I resolved the problem by adding
#include algorithm
after the end of the #include directives.
I don't know if this is the correct solution or whether this error is
specific to my system (daily updated Debian Sid). I know you are going
to
I'm writing some automated testing code for pieces of FG, so that I
can experiment with changes to various internal bits of code with more
confidence that I haven't broken anything. These aren't quite unit-
tests (they test multiple areas of the code at once) and they're
pretty crude, but
On 25 Aug 2008, at 07:31, Melchior FRANZ wrote:
I just made all internal runway data available in the Nasal query
function, without considering any possible use case. So far I only
used those elements that I needed for finding the touchdown point
($FG_ROOT/Nasal/glide_slope_tunnel.nas).
, 2008 at 3:53 PM, James Turner wrote:
Anyway, what makes me wonder if there's a bug here is the glideslope
logic. In the case where a glideslope angle is specified, and also a
preset altitude, we encounter the code at line 976 of fg_init.cxx.
Now, the crucial observation is that this code does
On 27 Aug 2008, at 10:36, Melchior FRANZ wrote:
Bah, I just saw a rather cheap 1TB disk offered in the ads of a shop
that focuses on books, music CDs and paper stuff. I guess that a
few MB more aren't really an issue nowadays. Hereby I withdraw the
above consideration. So what's left as an
On 27 Aug 2008, at 11:08, Martin Spott wrote:
What is your reason behind repeatedly expressing concerns wrt. storing
the base package in GIT ?
That git seems very code-orientated, and I don't know of anyone using
it as a binary data repository. It's a job CVS is dreadful at, of
course,
On 28 Aug 2008, at 20:51, Curtis Olson wrote:
Does this patch work with any aircraft and nav radio, or do the
individual aircraft need to be updated to match. I did a quick test
in the default c172 flying from SJC to SFO, but the SFO 28R ILS
seemed to have rock solid needle response
On 30 Aug 2008, at 23:16, Stefan C. Müller wrote:
As far as I can tell, this is not true. The third parameter type is
independant from the type of the container, and should only match
the type of the second parameter of the predicate. The current code
compile under MSVC 7.1 and under
On 30 Aug 2008, at 20:21, Martin Spott wrote:
I've compiled a tiny package. This includes the compiler error output
on Solaris10/SunStudio11 for those source files where it fails plus
the
single system header that is listed in the respective complaints:
On 31 Aug 2008, at 08:30, Frederic Bouvier wrote:
As Stefan says, the ( debugging ) code expects the predicate is
commutative. Maybe there is a symbol to disable debugging code to be
generated, or we could provide the class a second operator() :
bool operator()(const std::string aB, const
On 31 Aug 2008, at 08:49, Martin Spott wrote:
Without the slightest trouble - after applying a minor correction to
make the linker happy it even does on IRIX using MIPSpro. Either it's
not too difficult to get there or the guys at OSG simply have the
expertise about wiriting code to compile
On 31 Aug 2008, at 11:58, Stefan C. Müller wrote:
OK, here's the patch.
But we need a total of 3 overloaded operator(). Not realy nice to
look at.
Anyway, I'm happy with both variants.
As you say, not ideal, but I'm still working on this code, so a little
bit of uglyness, I can live
On 31 Aug 2008, at 21:57, Tim Moore wrote:
I guess you're not using map::lower_bound because you want to
support an
arbitrary ordering different from the map? What will the lower bound
result mean
in that case?
Actually my logic is busted anyway, I was hoping to avoid a linear
search
On 3 Sep 2008, at 14:05, Frederic Bouvier wrote:
there is another thing that is unclear to me. How GIT currently
interface with CVS ( and tomorrow SVN ) ?
How do you merge content from CVS in your GIT repository ?
How do you commit changes in CVS after commiting in GIT ?
The merge from
On 3 Sep 2008, at 14:24, Frederic Bouvier wrote:
You mean that it is Martin who do the 'cvs update' and we only have
to do
'git update' ( or whatever the command is ) ?
Not even Martin, it's an automatic sync, currently every 4 hours (I
think) for the src repository, of course this could
On 3 Sep 2008, at 17:37, Tim Moore wrote:
For the record, it's completely impractical to maintain a bi-
directional cvs-git
mirror system -- where committers can check into either the cvs or
the git
repository -- and probably only slightly less so to maintain a bi-
directional
svn-git
On 5 Sep 2008, at 09:09, James Turner wrote:
Just to be clear, what are the
exact steps to reproduce the crash? If you're using fgrun, I really
need to see the actual command line passed to fgfs.
Just tried locally with ./fgfs --airport=LFPN, and I don't crash, very
strange.
And checking
On 5 Sep 2008, at 15:24, Csaba Halász wrote:
Well, I had that disabled so I couldn't reproduce the bug either. But
enabling it indeed resulted in a crash.
Problem seems to be in AILocalTraffic.cxx, marked as TODO:
void FGAILocalTraffic::GetRwyDetails(const string id) {
//cout
On 5 Sep 2008, at 17:21, James Turner wrote:
Yep, that's quite a likely source - thanks for the help, I'll work out
from this.
Got it.
If someone could kindly apply the attached patch, that'll keep this
from crashing, I believe. The fix is easy since FGAirport can now
always provide
I've been carrying on with my experiments with my FGPositioned idea,
and I now have several of my original steps done:
- Fix, NavRecord, Airport and Runway all inherit the base class
- they all live on the heap, where previously Runway and Fix were
stack based, and hence rather heavy to
On 8 Sep 2008, at 20:25, Frederic Bouvier wrote:
Modified Files:
positioned.cxx
Log Message:
Add required include for lower_bound
Thanks Fred - wish I understood why the MSVC headers need this and GCC
doesn't.
Regards,
James
On 10 Sep 2008, at 23:09, Ron Jensen wrote:
As a result of these changes Terragear will no longer compile. Could
someone smarter than me in C++ fix the terragear sources to work with
these changes?
Whoops, my fault.
I'll get a patch done today.
James
On 11 Sep 2008, at 13:04, Ralf Gerlich wrote:
the CustomScenery-Version of TerraGear was already upgrade to cope
with
these changes.
Ah, thanks Ralf, that's good to know. I'm not really following
TerraGear development, are you generally submitting changes upstream
to the main terragear
On 13 Sep 2008, at 09:34, Frederic Bouvier wrote:
MSVC has a problem compiling this line :
return fabs(az1 90.0);
and I must admit I also have a problem understanding your intention.
You
are trying to extract the absolute value of a boolean. Should it be
return fabs(az1) 90.0;
On 22 Sep 2008, at 08:20, Erik Hofman wrote:
Did you already communicate the issue about the MK-VIII to other
developers in order to get it fixed ?
Yes, please report any problems that (seems to) have been introduced
recently, there was a lot of needed overhauling and just leaving it
buggy
On 22 Sep 2008, at 22:25, Vivian Meazza wrote:
AJ and I _think_ we are talking about the same problem. We might not
be,
although the description of the symptoms, which we have discussed many
times, seems to be the same. The underlying cause might not be the
same. It
might be the code,
On 22 Sep 2008, at 23:05, Vivian Meazza wrote:
A binary search, which I'm also trying, takes days. At some point we
left
OSG 2.4, used an interim version, then migrated to osg 2.6. An osg
rebuild
here takes well over an hour. So far, I've come about halfway
forward from
Apr, which
On 23 Sep 2008, at 20:26, Syd wrote:
So I gather your telling me I can't change my aircraft ? The gpws
issues
have been known for a long time , and I,m sure you well know that .
I wont post bugs here because of exactly this My past questions
were largely ignored , my minor patches
1 - 100 of 1199 matches
Mail list logo
