Re: [Flightgear-devel] [flightgear-devel]

2009-09-02 Thread Martin Spott
Behlül UÇAR wrote: Is there an exact version of newmat library which i need to download? Maybe i need to download it. The 'newmat11.tar.gz' should be fine (240888 bytes). Behlül UÇAR wrote: By the way, i'm trying to compile terragear-cs which i downloaded from cvs of flightgear. I also

Re: [Flightgear-devel] [flightgear-devel]

2009-09-02 Thread Behlül UÇAR
U're correct i meant git, http://mapserver.flightgear.org/git/ 2009/9/2 Martin Spott martin.sp...@mgras.net Behlül UÇAR wrote: Is there an exact version of newmat library which i need to download? Maybe i need to download it. The 'newmat11.tar.gz' should be fine (240888 bytes). Behlül

Re: [Flightgear-devel] Looking around while paused (FGViewMgr)

2009-09-02 Thread Martin Spott
James Turner wrote: A good lesson in how different people use different interfaces to the same functionality, and see different things :) plus an interesting lesson about one and the same feature behaving differently depending on which control you use ;-) Chheers, Martin. --

[Flightgear-devel] [flightgear-devel] cmdarg() function

2009-09-02 Thread Behlül UÇAR
Hi, I'm trying to create a route manager GUI which will store unlimited number of points with some extra parameters. For this reason, I've investigated $FG_ROOT/data/gui/dialogs/route-manager.xml file. At line 28 column 36, I saw a function named cmdarg(). I couldn't find any information about

Re: [Flightgear-devel] [flightgear-devel] cmdarg() function

2009-09-02 Thread James Turner
On 2 Sep 2009, at 13:45, Behlül UÇAR wrote: Hi, I'm trying to create a route manager GUI which will store unlimited number of points with some extra parameters. Hmm, what are you planning? I have some C++ changes to route-manager (almost a re-write) which make it work quite differently

Re: [Flightgear-devel] [flightgear-devel] cmdarg() function

2009-09-02 Thread Behlül UÇAR
Actually I'm planning on making a GUI which the user can enter unlimited number of points and 3 extra parameters with that points. After storing that points I want to make two controls. First control is a route control between the points (one-by-one, every point is appended the last point in the

[Flightgear-devel] Source code control systems

2009-09-02 Thread Curtis Olson
Source code control systems are close to religious topics for many people so I want to avoid potential panic here. I understand that due to the diversity of opinions within our developer community, it will be impossible to reach any kind of consensus for any action. Even the default of no action

Re: [Flightgear-devel] Source code control systems

2009-09-02 Thread Martin Spott
Curtis Olson wrote: What I propose is that we migrate our self hosted CVS repository to code.google.com and in the process convert to SVN. 1. This gives us professional management of the servers, regular professional backups, and an automatec access control system for adding new

Re: [Flightgear-devel] navradio.cxx

2009-09-02 Thread Victhor Foster
Is this good? It seems to be :) I had problems with GPSes before, as the CDI would just reset to zero and even if the CDI course is the same as the GPS bearing, the A/P won't follow the course, instead following the heading bug. Which is strange, because if NAV1 isn't set to be slaved to GPS, the

Re: [Flightgear-devel] Source code control systems

2009-09-02 Thread Tom P
Hi Curt My only concern with SVN is that it stores every file twice in the local file system, so it's not ideal for the 'data' portion of FlightGear. For example, right now a complete checkout of Aircraft is ~ 2 GB, and it would double overnight. I know, disk space is cheap in these days,

Re: [Flightgear-devel] Source code control systems

2009-09-02 Thread Curtis Olson
On Wed, Sep 2, 2009 at 2:02 PM, Tom P zomm...@gmail.com wrote: Hi Curt My only concern with SVN is that it stores every file twice in the local file system, so it's not ideal for the 'data' portion of FlightGear. For example, right now a complete checkout of Aircraft is ~ 2 GB, and it would

Re: [Flightgear-devel] Source code control systems

2009-09-02 Thread Matias D'Ambrosio
On Wed, Sep 2, 2009 at 4:02 PM, Tom P zomm...@gmail.com wrote: Hi Curt My only concern with SVN is that it stores every file twice in the local file system, so it's not ideal for the 'data' portion of FlightGear. For example, right now a complete checkout of Aircraft is ~ 2 GB, and it would

[Flightgear-devel] pilot list error

2009-09-02 Thread syd adams
As I mentioned before , I've been looking for the missing player in the pilot list and model view. If I comment out the 2 lines below foreach , in multiplayer.nas at line 374 ... foreach (var n; props.globals.getNode(ai/models, 1).getChildren(multiplayer)) { #if

Re: [Flightgear-devel] Source code control systems

2009-09-02 Thread Martin Spott
Curtis Olson wrote: Is this an argument to stay with CVS for the data portion of the project? I've been loosely monitoring the 'quality' of CVS checkouts for some time now and to my experience the number of silent transmission errors is most significant with the data repository. Therefore I

Re: [Flightgear-devel] Source code control systems

2009-09-02 Thread Matias D'Ambrosio
On Wed, Sep 2, 2009 at 4:19 PM, Curtis Olson curtol...@gmail.com wrote: On Wed, Sep 2, 2009 at 2:02 PM, Tom P zomm...@gmail.com wrote: Hi Curt My only concern with SVN is that it stores every file twice in the local file system, so it's not ideal for the 'data' portion of FlightGear. For

Re: [Flightgear-devel] Source code control systems

2009-09-02 Thread AJ MacLeod
On Wednesday 02 September 2009 22:44:56 Tom P wrote: Yes, I agree, a distributed system is overkill for the data portion. I would disagree... 1) data is handled well by a lightweight client-server model (either CVS or SVN) that: - allows users and developers to synchronize their local data

Re: [Flightgear-devel] navradio.cxx

2009-09-02 Thread James Turner
On 2 Sep 2009, at 19:55, Victhor Foster wrote: Is this good? It seems to be :) I had problems with GPSes before, as the CDI would just reset to zero and even if the CDI course is the same as the GPS bearing, the A/P won't follow the course, instead following the heading bug. Which is

Re: [Flightgear-devel] Source code control systems

2009-09-02 Thread Martin Spott
Tom P wrote: Well, it's more an argument in favor of splitting the data and source code, like it's already the case for the Scenery http://code.google.com/p/terrascenery/ Terrascenery is a somewhat special case in that it has almost just one single, automated feed, it is destined to never

Re: [Flightgear-devel] Source code control systems

2009-09-02 Thread Heiko Schulz
Hi, In case it wasn't clear by now... I think we should be using git for both source and data - as previously mentioned, many (if not most) FG developers are already using it (though missing many benefits that would arise from the main repo being git). Cheers, AJ I can only agree to AJ-

Re: [Flightgear-devel] Source code control systems

2009-09-02 Thread Tom P
Hi AJ, hi Martin I see the advantages of GIT, no need to be convinced of that. And I've had a look at the GIT projects on mapserver, very nice, and it's already split into source and data!!! But let's say that the project switched completely to GIT, would there be a way to support streaming

Re: [Flightgear-devel] Source code control systems

2009-09-02 Thread Csaba Halász
On Thu, Sep 3, 2009 at 12:17 AM, AJ MacLeodaj-li...@adeptopensource.co.uk wrote: In case it wasn't clear by now... I think we should be using git for both source and data - as previously mentioned, many (if not most) FG developers are already using it (though missing many benefits that would

Re: [Flightgear-devel] [DRAFT] generic input devices and hotplug support

2009-09-02 Thread Tatsuhiro Nishioka
Hi, Attached is a patch for FGMacOSXEventInput.[ch]xx Torsten, Could you commit it with the following comments: - Fixed: wrong event name for abs-hat0-y Modified: let AxisElement to generate normalized input (-1.0 to 1.0). This can be temporal and