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 > 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:

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 th

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 ch

[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

[Flightgear-devel] navradio.cxx

2009-09-02 Thread James Turner
I've just committed a large patch to the navradio code, which re- structures the code, with the aim of increasing the readability (and maintainability) significantly. This is in preparation for some other changes, especially making the 'NAV/GPS switch' function more explicit, and hopefully r

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 > dev

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 A

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, bu

Re: [Flightgear-devel] Source code control systems

2009-09-02 Thread Curtis Olson
On Wed, Sep 2, 2009 at 2:02 PM, Tom P 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 > double ove

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 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 > double ove

[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 (!n.getN

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 don

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 wrote: > On Wed, Sep 2, 2009 at 2:02 PM, Tom P 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 comp

Re: [Flightgear-devel] Source code control systems

2009-09-02 Thread Tom P
Curtis Olson wrote: On Wed, Sep 2, 2009 at 2:02 PM, Tom P > 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 c

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 d

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 stra

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 A

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 s

Re: [Flightgear-devel] Source code control systems

2009-09-02 Thread Csaba Halász
On Thu, Sep 3, 2009 at 12:17 AM, AJ MacLeod 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 arise from the > main repo b

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 can

Re: [Flightgear-devel] Source code control systems

2009-09-02 Thread Martin Spott
Hi Tom, Tom P wrote: > But let's say that the project switched completely to GIT, would there > be a way to support streaming scenery ('terrasync') to the user without > him/her needing to clone the entire fgdata repository ? Terrascenery is a totally independent affair and therefore not affec