Re: [Flightgear-devel] AI problems in CVS

2006-02-25 Thread James Turner
On 25 Feb 2006, at 07:46, Pigeon wrote:    Just thought someone might want to know about this, with current SG/FG cvs, if I have /sim/ai/enabled (i.e. --prop:/sim/ai/enabled=true), starting FG at KSFO (probably not KSFO specific) gives me this:     Attempting to schedule tiles for bogus lon and

Re: [Flightgear-devel] MAC OS-X developer request

2006-03-07 Thread James Turner
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

Re: [Flightgear-devel] Nasal in dialog XML files

2006-03-08 Thread James Turner
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

[Flightgear-devel] Pilot models

2006-03-24 Thread James Turner
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

Re: [Flightgear-devel] Re: new contribution

2006-03-27 Thread James Turner
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

Re: [Flightgear-devel] Re: Citation autopilot...

2006-03-27 Thread James Turner
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

Re: [Flightgear-devel] Graphics load

2006-04-03 Thread James Turner
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

[Flightgear-devel] 0.9.10 pre-release binary for OS-X

2006-04-04 Thread James Turner
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,

Re: [Flightgear-devel] 0.9.10 pre-release binary for OS-X

2006-04-05 Thread James Turner
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

Re: [Flightgear-devel] Re: simgear for Mac OS X Tiger

2006-04-06 Thread James Turner
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

Re: [Flightgear-devel] [PATCH] Re: UIUC FDM

2006-04-09 Thread James Turner
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

Re: [Flightgear-devel] FC2 .rpm on FlightGear website being distributed with freeglut 2.4!

2006-04-10 Thread James Turner
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

Re: [Flightgear-devel] MacOS version of v0.9.10 ?

2006-04-11 Thread James Turner
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

Re: [Flightgear-devel] MacOS build of FlightGear

2006-04-14 Thread James Turner
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

Re: [Flightgear-devel] MacOS build of FlightGear

2006-04-15 Thread James Turner
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

Re: [Flightgear-devel] MacOS build of FlightGear

2006-04-16 Thread James Turner
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

Re: [Flightgear-devel] MacOS build of FlightGear

2006-04-16 Thread James Turner
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

[Flightgear-devel] Subsystem run-levels

2006-04-17 Thread James Turner
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

Re: [Flightgear-devel] Subsystem run-levels

2006-04-18 Thread James Turner
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,

Re: [Flightgear-devel] Re: Subsystem run-levels

2006-04-18 Thread James Turner
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

Re: [Flightgear-devel] Re: Subsystem run-levels

2006-04-18 Thread James Turner
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

Re: [Flightgear-devel] Re: Subsystem run-levels

2006-04-18 Thread James Turner
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

Re: [Flightgear-devel] Re: Subsystem run-levels

2006-04-18 Thread James Turner
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'

Re: [Flightgear-devel] Re: simgear for Mac OS X Tiger

2006-04-21 Thread James Turner
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

Re: [Flightgear-devel] MacOS version of v0.9.10 ?

2006-04-22 Thread James Turner
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. 

Re: [Flightgear-devel] Nasal function and keyboard shortcut for autobrake functionality

2006-04-28 Thread James Turner
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 :

Re: [Flightgear-devel] Compiling SimGear 0.3.10 on OS X

2006-07-07 Thread James Turner
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

[Flightgear-devel] Legacy #ifdefs

2008-07-24 Thread James Turner
(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

Re: [Flightgear-devel] Legacy #ifdefs

2008-07-24 Thread James Turner
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

Re: [Flightgear-devel] Legacy #ifdefs

2008-07-24 Thread James Turner
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

Re: [Flightgear-devel] Legacy #ifdefs

2008-07-24 Thread James Turner
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.

[Flightgear-devel] Mac #ifdef clean-ups

2008-07-25 Thread James Turner
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

[Flightgear-devel] windows.h

2008-07-27 Thread James Turner
(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

Re: [Flightgear-devel] windows.h

2008-07-27 Thread James Turner
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

Re: [Flightgear-devel] windows.h

2008-07-27 Thread James Turner
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

Re: [Flightgear-devel] windows.h

2008-07-27 Thread James Turner
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

[Flightgear-devel] Header cleanups (was Re: windows.h)

2008-07-28 Thread James Turner
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

[Flightgear-devel] Project tracking

2008-07-28 Thread James Turner
(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

Re: [Flightgear-devel] Mac #ifdef clean-ups

2008-07-29 Thread James Turner
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)

Re: [Flightgear-devel] using std::

2008-07-30 Thread James Turner
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::

Re: [Flightgear-devel] using std::

2008-07-30 Thread James Turner
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

[Flightgear-devel] Cockpit displays (rendering, modelling)

2008-08-03 Thread James Turner
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

Re: [Flightgear-devel] Cockpit displays (rendering, modelling)

2008-08-03 Thread James Turner
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

Re: [Flightgear-devel] Cockpit displays (rendering, modelling)

2008-08-03 Thread James Turner
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

Re: [Flightgear-devel] Cockpit displays (rendering, modelling)

2008-08-04 Thread James Turner
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,

Re: [Flightgear-devel] Cockpit displays (rendering, modelling)

2008-08-04 Thread James Turner
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

Re: [Flightgear-devel] Cockpit displays (rendering, modelling)

2008-08-04 Thread James Turner
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),

Re: [Flightgear-devel] 3D clouds - progress report·

2008-08-09 Thread James Turner
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

Re: [Flightgear-devel] OpenAL and ALUT

2008-08-14 Thread James Turner
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

Re: [Flightgear-devel] OpenAL and ALUT

2008-08-14 Thread James Turner
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

[Flightgear-devel] Runways

2008-08-14 Thread James Turner
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

[Flightgear-devel] FGNavList oddity

2008-08-15 Thread James Turner
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

Re: [Flightgear-devel] FGNavList oddity

2008-08-15 Thread James Turner
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

[Flightgear-devel] FGPositioned refactoring

2008-08-15 Thread James Turner
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

Re: [Flightgear-devel] FGPositioned refactoring

2008-08-16 Thread James Turner
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,

Re: [Flightgear-devel] FGPositioned refactoring

2008-08-16 Thread James Turner
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

[Flightgear-devel] KLN89 waypoints clean-up

2008-08-16 Thread James Turner
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

Re: [Flightgear-devel] FGPositioned refactoring

2008-08-17 Thread James Turner
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

Re: [Flightgear-devel] GIT; Was: _Sport Model_

2008-08-17 Thread James Turner
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

Re: [Flightgear-devel] a few service-volume bugs

2008-08-17 Thread James Turner
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

Re: [Flightgear-devel] strange FG crash

2008-08-18 Thread James Turner
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

Re: [Flightgear-devel] strange FG crash

2008-08-18 Thread James Turner
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

Re: [Flightgear-devel] Textranslate Step and Scroll

2008-08-19 Thread James Turner
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

Re: [Flightgear-devel] FGPositioned refactoring

2008-08-19 Thread James Turner
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

[Flightgear-devel] Further FGRunway work

2008-08-20 Thread James Turner
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

Re: [Flightgear-devel] GIT / SVN

2008-08-20 Thread James Turner
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

Re: [Flightgear-devel] Sound positioning and orientation

2008-08-21 Thread James Turner
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

Re: [Flightgear-devel] Sound positioning and orientation

2008-08-21 Thread James Turner
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

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Sound fg_fx.cxx, 1.26, 1.27 fg_fx.hxx, 1.17, 1.18

2008-08-21 Thread James Turner
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(),

Re: [Flightgear-devel] Sound positioning and orientation

2008-08-21 Thread James Turner
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

Re: [Flightgear-devel] Sound positioning and orientation

2008-08-21 Thread James Turner
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

Re: [Flightgear-devel] GIT

2008-08-21 Thread James Turner
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

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Sound fg_fx.cxx, 1.26, 1.27 fg_fx.hxx, 1.17, 1.18

2008-08-21 Thread James Turner
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.

Re: [Flightgear-devel] fixlist.cxx compile error

2008-08-22 Thread James Turner
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

[Flightgear-devel] Startup position offsets (fg_init)

2008-08-24 Thread James Turner
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

Re: [Flightgear-devel] Further FGRunway work

2008-08-25 Thread James Turner
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).

Re: [Flightgear-devel] Startup position offsets (fg_init)

2008-08-25 Thread James Turner
, 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

Re: [Flightgear-devel] GIT

2008-08-27 Thread James Turner
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

Re: [Flightgear-devel] GIT

2008-08-27 Thread James Turner
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,

Re: [Flightgear-devel] improving VOR indication (patch for navradio.cxx/hxx)

2008-08-28 Thread James Turner
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

Re: [Flightgear-devel] Patch: Minor bugfixes for MSVC compatibility

2008-08-30 Thread James Turner
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

Re: [Flightgear-devel] Legacy #ifdefs

2008-08-30 Thread James Turner
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:

Re: [Flightgear-devel] Patch: Minor bugfixes for MSVC compatibility

2008-08-31 Thread James Turner
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

Re: [Flightgear-devel] Legacy #ifdefs

2008-08-31 Thread James Turner
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

Re: [Flightgear-devel] Patch: Minor bugfixes for MSVC compatibility

2008-08-31 Thread James Turner
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

Re: [Flightgear-devel] Patch: Minor bugfixes for MSVC compatibility

2008-09-01 Thread James Turner
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

Re: [Flightgear-devel] GIT

2008-09-03 Thread James Turner
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

Re: [Flightgear-devel] GIT

2008-09-03 Thread James Turner
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

Re: [Flightgear-devel] GIT

2008-09-03 Thread James Turner
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

Re: [Flightgear-devel] LFPN Problem

2008-09-05 Thread James Turner
On 5 Sep 2008, at 07:30, Durk Talsma wrote: Your bug report reminds me of a similar one that was reported a few weeks ago. We recently overhauled the runway search code, and in the process it is possible that either a new bug was introduced, or that the new code exposed existing

Re: [Flightgear-devel] LFPN Problem

2008-09-05 Thread James Turner
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

Re: [Flightgear-devel] LFPN Problem

2008-09-05 Thread James Turner
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

Re: [Flightgear-devel] LFPN Problem

2008-09-06 Thread James Turner
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

[Flightgear-devel] FGPositioned update

2008-09-06 Thread James Turner
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

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Navaids positioned.cxx, 1.1, 1.2

2008-09-09 Thread James Turner
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

Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear compiler.h, 1.29, 1.30

2008-09-11 Thread James Turner
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

Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear compiler.h, 1.29, 1.30

2008-09-11 Thread James Turner
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

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Navaids navdb.cxx, 1.27, 1.28 navdb.hxx, 1.11, 1.12 navlist.cxx, 1.21, 1.22 navlist.hxx, 1.17, 1.18 navrecord.cxx, 1.1, 1.2 navrecord.hxx, 1

2008-09-13 Thread James Turner
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;

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/b1900d b1900d-set.xml, 1.32,

2008-09-22 Thread James Turner
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

Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system

2008-09-22 Thread James Turner
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,

  1   2   3   4   5   6   7   8   9   10   >