Re: [Flightgear-devel] The future of FlightGear's support programs

2011-09-05 Thread Durk Talsma
On 04 Sep 2011, at 14:54, James Turner wrote:

 
 On 4 Sep 2011, at 07:05, Durk Talsma wrote:
 
 If not, I might consider moving the taxidraw source over to gitorious and 
 incorporate it as a subproject of fg. 
 
 Any thoughts / ideas would be welcome. 
 
 I think this is best answer - for programs the original author wishes others 
 to maintain / bugfix / enhance, they should live in the fg Gitorious project 
 (not necessarily the flightgear repository, of course). This could 
 potentially be done for Atlas, mpserver, and so on, if that helps 
 development. 

I agree; but ultimately, it should be up to the project admins whether they 
would prefer that or not. 

 
 Are there reasons *against* moving support programs into the fg project? 
 Assuming the original developer is happy with other people on the flightgear 
 committers list potentially apply patches / bugfixes, of course.

but I guess a slightly more refined version of my question is what to do when 
the original author / project admin no longer responds. I cannot recall what 
the actual situation is with regard to TaxiDraw. Last time I was in contact 
with David Luff, he mentioned that he would like to keep responsibility for the 
gps code, and was happy to abandon his ATC project. I also seem to recall that 
he mentioned something about taxidraw, but I'm not sure anymore what he wrote 
in this regard. Hopefully, I can find the email somewhere in my archieve and 
take it from there. 



 
 Presumably we're require all such code to use the same license as FG or SG 
 (i.e either GPL or LGPL) to avoid headaches and confusion.
 
 

Taxidraw is gpl licenced, so that shouldn't be a problem. 


On a more general note; while I think the discussion is about potential 
taxidraw substitutes is interesting (and also on topic considering my 
slightly broad subject title), I would like to mention that in addition to the 
GIS based tools, taxidraw is also the defacto tool for AI development. It is 
the most complete editing tool for creating ground networks,  parking 
locations, etc etc. As such, it remains a vital and necessary tool.

Cheers,
Durk
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Two aircraft-related issues

2011-09-05 Thread thorsten . i . renk
 ZLT-NT and Nordstern: I can't place the mooring mast, which is supposed
 to be alt+click.

 I would suspect the window manager, both aircraft use the same mechanism
 and I've seen it working here as recently as yesterday. It should be a
 left click while holding the (left, on my keyboard) Alt key.

And got it working (without changing code) with crtl+alt+click - no idea
why, but it certainly does the trick.

Cheers,

* Thorsten


--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Cmake

2011-09-05 Thread Alan Teeder
Please don´t.

I reverted from VC100 to VC90 as the Cmake process was always failing. 
There is a difference between Hudson saying that all is OK with Cmake and 
Visual Studio VC100 producing working executables.

This was all with the de-facto standard 3rd party package from 
ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/.

I could get the system to work, but then it would all go wrong after a few 
days or weeks. On the other hand the current VC90 project files seem quite 
robust.

Just my experience.

Alan


--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Links for new FlightGear pilots

2011-09-05 Thread Stuart Buchanan
On 1 Sep 2011, at 08:37, Jörg Emmerich wrote:
 I wanted to introduce that outcome about end of this month to the
 dev-team, to see especially whether the Originators of the getstart
 still find their share in what I did, and concur to this change. I hope
 nobody feels offended by my partly drastic changes to their origin. You
 will see that I still list the Originators and just claim the
 Revision for myself. 
 
 Any comments, critics, suggestions, improvements, etc. are highly
 welcome.
 
 joe (jomo)

Hi jomo,

Firstly, thanks very much for looking at improving The Manual. 

I'm currently on vacation so haven't had the chance to look at your work in 
detail but thought I should comment in case you thought you were being ignored 
by the maintainers.

One immediate question is how you see your changes being incorporated into to 
latex source code?

Producing a nice PDF is quite important for a lot of people so I wouldn't want 
to lose that. 

More comments when I get the time once I'm back. 

Best regards

-Stuart
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Cmake

2011-09-05 Thread Mathias Fröhlich

Hi,

On Monday, September 05, 2011 14:47:44 Alan Teeder wrote:
 Please don´t.
 
 I reverted from VC100 to VC90 as the Cmake process was always failing.
 There is a difference between Hudson saying that all is OK with Cmake and
 Visual Studio VC100 producing working executables.
 
 This was all with the de-facto standard 3rd party package from
 ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/.
 
 I could get the system to work, but then it would all go wrong after a few
 days or weeks. On the other hand the current VC90 project files seem quite
 robust.

Then please tell what is going wrong.
This is like every piece of code lingering around in this and similar 
projects. The people doing the changes do their best to make it work. But if 
there is something failing on some other platform/configuration/... feedback is 
needed.

Thanks

Mathias

--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Cmake

2011-09-05 Thread Curtis Olson
So I have nothing against cmake, it sounds like it offers some nice
features.  But I assume those that want to push this change forward, will
take some time to write up some basic howto's so that people who have never
used it as a developer can get up to speed without too many problems?

Right now when I poke around on the wiki and I'm sure the getstart manual,
all the instructions are automake based.  Hopefully  we can do some
proactive hunting of automake references in our instructions scattered
around and get those cleaned up in advance?

Are there any cmake based build instructions available anywhere?  I'm not
seeing them.

When building OSG, you run ./configure; make; make install like any other
project.  However, ./configure is an automake/conf generated in flightgear.
 For a cmake dummy, how do you even go about building flightgear with cmake?
 (I of course know everything, but I do have a friend who's a little
inexperienced with cmake.)

Is there a way to do the equivalent of make dist in cmake to generate
.tar.gz source releases?  Has this been tested to see if it includes all the
necessary files?

We have some extra automake rules to help create the data archives (which is
important because this officially defines what goes into the release
installer for both Mac and Windows as well as the data archive for people
building from source code (who aren't doing 3Gb of git for the data tree.))

I'm just hoping the cmake jocks will put themselves in the position of
non-cmake jocks and help ease the transition from multiple fronts for many
of our different classes of users/developers.

Thanks!

Curt.


2011/9/5 Mathias Fröhlich mathias.froehl...@gmx.net


 Hi,

 On Monday, September 05, 2011 14:47:44 Alan Teeder wrote:
  Please don´t.
 
  I reverted from VC100 to VC90 as the Cmake process was always failing.
  There is a difference between Hudson saying that all is OK with Cmake and
  Visual Studio VC100 producing working executables.
 
  This was all with the de-facto standard 3rd party package from
  ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/.
 
  I could get the system to work, but then it would all go wrong after a
 few
  days or weeks. On the other hand the current VC90 project files seem
 quite
  robust.

 Then please tell what is going wrong.
 This is like every piece of code lingering around in this and similar
 projects. The people doing the changes do their best to make it work. But
 if
 there is something failing on some other platform/configuration/...
 feedback is
 needed.

 Thanks

 Mathias


 --
 Special Offer -- Download ArcSight Logger for FREE!
 Finally, a world-class log management solution at an even better
 price-free! And you'll get a free Love Thy Logs t-shirt when you
 download Logger. Secure your free ArcSight Logger TODAY!
 http://p.sf.net/sfu/arcsisghtdev2dev
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel




-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Cmake

2011-09-05 Thread Martin Spott
Curtis Olson wrote:

 I'm just hoping the cmake jocks will put themselves in the position of
 non-cmake jocks and help ease the transition from multiple fronts for many
 of our different classes of users/developers.

With CMake there's a list of flags you're appending to the 'cmake' call
similarly to calling 'configure' with custom flags - and with no flags
at all it'll create a default build for you depending on the
prerequisites installed on your system.  Thus, there's nothing terribly
different from Automake   except from the fact that you will
_always_ have to append the source directory for CMake - which will be
a simple trailing dot for in-tree-builds  ;-)

Rest assured that work to bring the CMake build system for SimGear and
FlightGear onto the same level as the former build systems is already
in progress.

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Cmake

2011-09-05 Thread Curtis Olson
Is there support for the --prefix= concept of autoconf?  I really struggled
to find anything like that in OSG's cmake config and it appeared I would be
forced to define a really ugly/long list of environment variables before
running make install in order to accomplish a similar thing (installing
somewhere other than /usr/local/ or using an installation somewhere outside
of /usr/local/

In the end I just gave my hope to manage a couple different versions of osg,
and just wrote over my older version with the newer version.

Thanks,

Curt.


On Mon, Sep 5, 2011 at 11:25 AM, Martin Spott wrote:

 Curtis Olson wrote:

  I'm just hoping the cmake jocks will put themselves in the position of
  non-cmake jocks and help ease the transition from multiple fronts for
 many
  of our different classes of users/developers.

 With CMake there's a list of flags you're appending to the 'cmake' call
 similarly to calling 'configure' with custom flags - and with no flags
 at all it'll create a default build for you depending on the
 prerequisites installed on your system.  Thus, there's nothing terribly
 different from Automake   except from the fact that you will
 _always_ have to append the source directory for CMake - which will be
 a simple trailing dot for in-tree-builds  ;-)

 Rest assured that work to bring the CMake build system for SimGear and
 FlightGear onto the same level as the former build systems is already
 in progress.

 Cheers,
Martin.
 --
  Unix _IS_ user friendly - it's just selective about who its friends are !
 --


 --
 Special Offer -- Download ArcSight Logger for FREE!
 Finally, a world-class log management solution at an even better
 price-free! And you'll get a free Love Thy Logs t-shirt when you
 download Logger. Secure your free ArcSight Logger TODAY!
 http://p.sf.net/sfu/arcsisghtdev2dev
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel




-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Links for new FlightGear pilots

2011-09-05 Thread Peter Morgan
anyone looked at docbook. It would solve the problem.. but its a horrible to
use.. but there again that was with my experience a few years ago doing a
major update to smarty.php (had to it as my team was using it and was paid
as thus by my boss)

I certainly think that a html5/xml approach is cool approach.. nowadays
and wish to help... I dont like pdf's when I try to mix or even knock them
off from the server live, unlike other archived docs... pdf editing to
me is an art form..

But IMHO we would need to take the markup approach from now.. maybe even a
fresh start... and cut and paste stuff across..
eg
article
   section land=enthis is english, and maybe the source/section
   section lang=dethis a lang section but also maybe this last line a
source/section
   section lang=edthis aanother lang section/section
/article

certainly having files side by side can be a good way of translating..
eg a geman commit -  to
/ils/glideslope.en.html !--  please fix spelling mistake... ;-) --
/ils/glideslope.ge.html !-- correcting english mistake... ;-) --

and thus an observation by another to translate file in same patch and
topic...
ALso..
me need to structure the manual into chapters.. but obvious ones in
directories that diectly map to url's
eg
/aiports/atc
/airport/runway/papi
/glossay/atc, papi,


I still like Jomo idea of a flight school very much.. starting from the
bottom up.. from a cadet to a commander, atc et all

Certainly though, looking toward the future and more usage.. and more eyes..
we should plan for that, not only in printed media.. but in game help of
ipods of a website browsing on an olde retired FG machine

The main issue to consider is whether is actually a flight manual of now
to fly an aircaft, or the simulation ..  or both

We'd need to make it original and copyrightable to every contibutor to
make it 100% proof..

just some thoughts...

pete






On Mon, Sep 5, 2011 at 2:45 PM, Stuart Buchanan stuar...@gmail.com wrote:

 On 1 Sep 2011, at 08:37, Jörg Emmerich wrote:
  I wanted to introduce that outcome about end of this month to the
  dev-team, to see especially whether the Originators of the getstart
  still find their share in what I did, and concur to this change. I hope
  nobody feels offended by my partly drastic changes to their origin. You
  will see that I still list the Originators and just claim the
  Revision for myself.
 
  Any comments, critics, suggestions, improvements, etc. are highly
  welcome.
 
  joe (jomo)

 Hi jomo,

 Firstly, thanks very much for looking at improving The Manual.

 I'm currently on vacation so haven't had the chance to look at your work in
 detail but thought I should comment in case you thought you were being
 ignored by the maintainers.

 One immediate question is how you see your changes being incorporated into
 to latex source code?

 Producing a nice PDF is quite important for a lot of people so I wouldn't
 want to lose that.

 More comments when I get the time once I'm back.

 Best regards

 -Stuart

 --
 Special Offer -- Download ArcSight Logger for FREE!
 Finally, a world-class log management solution at an even better
 price-free! And you'll get a free Love Thy Logs t-shirt when you
 download Logger. Secure your free ArcSight Logger TODAY!
 http://p.sf.net/sfu/arcsisghtdev2dev
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Cmake

2011-09-05 Thread Curtis Olson
Is this an option to cmake at the configure step, or to make at the
build/install step?  Can this work as an environment variable?  What if I
want to pick up build libraries from a non-standard location ... maybe I'd
like to install a particular version of FG and a particular version of all
it's prerequisites somewhere strange like /opt/FlightGear-2.4/ so everything
it needs is self contained there and I can have other versions of the
prerequisites elsewhere?

The automake --prefix= option was sort of an all in one thing.  It not only
added this to the *front* of the include and library search path for
compiling, but it also defined the install paths such as $prefix/lib,
$prefix/include, $prefix/bin, etc. where everything would be placed when
make install is run.

Thanks,

Curt.


On Mon, Sep 5, 2011 at 11:37 AM, Martin Spott martin.sp...@mgras.netwrote:

 Curtis Olson wrote:

  Is there support for the --prefix= concept of autoconf?

   -D CMAKE_INSTALL_PREFIX=${FG_HOME}

 Cheers,
Martin.
 --
  Unix _IS_ user friendly - it's just selective about who its friends are !
 --


 --
 Special Offer -- Download ArcSight Logger for FREE!
 Finally, a world-class log management solution at an even better
 price-free! And you'll get a free Love Thy Logs t-shirt when you
 download Logger. Secure your free ArcSight Logger TODAY!
 http://p.sf.net/sfu/arcsisghtdev2dev
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel




-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] flight recorder / replay system

2011-09-05 Thread Robert
Thorsten, this is just amazing!

One question I need to ask:
What is the recording frequency? Can it be adjusted by the user?

cheers
Robert

2011/9/4 ThorstenB bre...@gmail.com

 Hi,

 I'm currently looking into an overhaul of the replay system. The buffer
 mechanisms of the existing replay system itself won't change, but I'm
 replacing the hard-coded recorder/FDM interface. Instead, I'll introduce
 a fully configurable flight recorder. It's basically a property
 recorder, so anything that's in the property tree can be recorded - and
 replayed. Aircraft-specific XML descriptions can be used to specify
 properties, data type and interpolation method (discrete, linear, or
 rotational in degrees/radiant) for each signal.

 There'll be a set of default property lists which can be included, so
 only custom properties need to be specified manually. Naturally, all
 (existing) aircraft not providing any recorder configuration will use a
 default, matching the hard-coded system of = FG 2.4.0.

 I have a prototype which also shows the new system is going to be
 faster, mainly since it doesn't resolve property paths at run-time and
 avoids copying data around. It'll also use less memory, since most
 properties can be recorded with reduced precision, e.g. it's unnecessary
 to record things like flap or gear position with full double
 precision. And the current system always records properties for 4
 engines + 4 propellers + 6 tanks + 3 gear. With the new system, this can
 be easily adapted - a glider doesn't even need
 tank/gear/engine/propeller properties. On the other hand, most jet
 engine properties weren't recorded so far - this will also improve. And
 the obvious advantage of the new system is the option of recording
 custom properties.

 Finally, the new system also comes with a new replay dialog. Looks
 more like a video player, provides a time slider and, also new,
 introduces slow-motion play back. Sneak preview:
 http://imageshack.us/photo/my-images/683/fgfsreplay.png/

 I have a working prototype, but nothing ready to be committed.
 Meanwhile, constructive comments/ideas are welcome.

 cheers,
 Thorsten



 --
 Special Offer -- Download ArcSight Logger for FREE!
 Finally, a world-class log management solution at an even better
 price-free! And you'll get a free Love Thy Logs t-shirt when you
 download Logger. Secure your free ArcSight Logger TODAY!
 http://p.sf.net/sfu/arcsisghtdev2dev
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] ATC and radio signal attenuation

2011-09-05 Thread Durk Talsma
Hi Adrian,



 
 So far, only ground to AI aircraft and AI aircraft to ground is implemented, 
 as part of the FGATCController class.
 This system, if proven functional, should probably be split into a separate 
 module and applied to all comunication, including player-to-ground and player-
 to-player.
 All code is available in my clone, branch radio-att.
 

I'm a little pressed for time this week, so I have to keep my response a little 
on the short side. In essence, I think that this would be any extremely cool 
feature to have. Do you already have a working copy that you would consider 
merging with flightgear/next? If so, I would like to do so and give it a shot 
(after having tried it locally and after ensuring that everything works okay). 

So far, I only have one humble request, which is an option to conditionally 
disable it. Although I haven't really had the need to listen to distant 
stations yet, I can imagine that certain situations will arise where I need to 
be able to follow ATC messages across larger distances. Given that during the 
development cycle I would rather concentrate on debugging than on deciphering a 
radio message, I think that an option to conditionally disable ATC signal 
attenuation would be very welcome.


Cheers,
Durk
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] RE : Cmake

2011-09-05 Thread Frederic Bouvier
My intention is, with the help of James and Gene, to convert the current 
Jenkins build to VS2010 and Cmake in the next few weeks. Cmake and VS2010 
combinaison has always worked for me, and I am interested to here about issues.

Regards,
-Fred

Alan Teeder ajtee...@v-twin.org.uk a écrit :

Please don´t.

I reverted from VC100 to VC90 as the Cmake process was always failing. 
There is a difference between Hudson saying that all is OK with Cmake and 
Visual Studio VC100 producing working executables.

This was all with the de-facto standard 3rd party package from 
ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/.

I could get the system to work, but then it would all go wrong after a few 
days or weeks. On the other hand the current VC90 project files seem quite 
robust.

Just my experience.

Alan

--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] ATC and radio signal attenuation

2011-09-05 Thread Alex Perry
If you know the phone number of the ATC facility, you should be able
to enter it into a popup that looks like a satphone and communicate
with them without the attenuation constraint.  Oh, and extend the ATC
dialog to understand say phone number and on landing call
interactions.

On Mon, Sep 5, 2011 at 10:01 AM, Durk Talsma durkt...@gmail.com wrote:
 Hi Adrian,




 So far, only ground to AI aircraft and AI aircraft to ground is implemented,
 as part of the FGATCController class.
 This system, if proven functional, should probably be split into a separate
 module and applied to all comunication, including player-to-ground and 
 player-
 to-player.
 All code is available in my clone, branch radio-att.


 I'm a little pressed for time this week, so I have to keep my response a 
 little on the short side. In essence, I think that this would be any 
 extremely cool feature to have. Do you already have a working copy that you 
 would consider merging with flightgear/next? If so, I would like to do so and 
 give it a shot (after having tried it locally and after ensuring that 
 everything works okay).

 So far, I only have one humble request, which is an option to conditionally 
 disable it. Although I haven't really had the need to listen to distant 
 stations yet, I can imagine that certain situations will arise where I need 
 to be able to follow ATC messages across larger distances. Given that during 
 the development cycle I would rather concentrate on debugging than on 
 deciphering a radio message, I think that an option to conditionally disable 
 ATC signal attenuation would be very welcome.


 Cheers,
 Durk
 --
 Special Offer -- Download ArcSight Logger for FREE!
 Finally, a world-class log management solution at an even better
 price-free! And you'll get a free Love Thy Logs t-shirt when you
 download Logger. Secure your free ArcSight Logger TODAY!
 http://p.sf.net/sfu/arcsisghtdev2dev
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel


--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Cmake

2011-09-05 Thread Alan Teeder
-Original Message- 
From: MathiasFröhlich
Sent: Monday, September 05, 2011 4:28 PM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Cmake


Hi,

On Monday, September 05, 2011 14:47:44 Alan Teeder wrote:
 Please don´t.

 I reverted from VC100 to VC90 as the Cmake process was always failing.
 There is a difference between Hudson saying that all is OK with Cmake and
 Visual Studio VC100 producing working executables.

 This was all with the de-facto standard 3rd party package from
 ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/.

 I could get the system to work, but then it would all go wrong after a few
 days or weeks. On the other hand the current VC90 project files seem quite
 robust.

Then please tell what is going wrong.
This is like every piece of code lingering around in this and similar
projects. The people doing the changes do their best to make it work. But if
there is something failing on some other platform/configuration/... feedback 
is
needed.

Thanks

Mathias
---
Mathias

I did, but I am afraid that your reply did not address my question.

When I did get it working, every time that there was a change requiring a 
new set of project files, Cmake got very confused and came up with new sets 
of problems.

Each time that I deleted the cache (to start afresh when cmake gave up), 
cmake wanted loads of info, most of which it should have known as my 
flightgear folder layout is the standard one.  Boringly,  I had to re-enter 
the location of every simgear library, as well as openal and zlib which 
already existed in the 3rd party structure.

A few more hiccups, which I can no longer remember, VS  produced  an 
executable  However this would not run and usually involved using the 
depends tool to work out why FG had been made with the wrong set of 
libraries.

The final straw came with the incorporation of HLA, which I never sorted 
out.

VC100 is to be avoided like the plague. It even seems to have problems 
linking with libraries produced with different versions of VC100.

Alan 


--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Cmake

2011-09-05 Thread Martin Spott
Curtis Olson wrote:

 Is this an option to cmake at the configure step, or to make at the
 build/install step?

The install prefix is set at the configure step - CMake is quite
similar to Autoconf in this respect.  To put an example, configuring
SimGear on a setup with TerraSync/SVN explicitly disabled would look
like this:

  # ${SRC}/simgear  cmake -D CMAKE_INSTALL_PREFIX=${FG_HOME} -D 
ENABLE_LIBSVN=OFF .
  # ${SRC}/simgear  make
  # ${SRC}/simgear  make install

Additional flags are optional, similarly to Automake.

 [...]  What if I
 want to pick up build libraries from a non-standard location ... maybe I'd
 like to install a particular version of FG and a particular version of all
 it's prerequisites somewhere strange like /opt/FlightGear-2.4/ so everything
 it needs is self contained there and I can have other versions of the
 prerequisites elsewhere?

CMake in FlightGear does exactly this. configure  eeeh, cmake
with -D CMAKE_INSTALL_PREFIX=${FG_HOME} and it'll find SimGear in
exactly this place.  At least it's working this way for me and we'll
try to make sure it will work on other people's setups the same way -
if it doesn't already do so.  Custom flags to find custom
pre-requisites in custom places are being applied in a familiar manner
(like -D RTI_LIBRARY=/opt/OpenRTI/lib/libRTI-NG.so for example).

There are six weeks left until we're caught by the Automake deadline,
two more months until feature freeze plus another two months until
release.  I'm pretty certain that's sufficient time to get the pending
issues ironed out until release - at least for those setups whose
maintainers are seriously interested in having a working build.

Well, you'll never catch 100 % of the help me, my build is broken -
but I won't tell you, how 's - that's life  ;-)

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] flight recorder / replay system

2011-09-05 Thread ThorstenB
On 05.09.2011 18:48, Robert wrote:
 One question I need to ask:
 What is the recording frequency? Can it be adjusted by the user?

The replay system uses three buffer levels: short term memory records 60 
seconds at full frame rate, mid term buffer records another 10 minutes 
at 2fps, and the long term buffer holds 1 hour at 1/5fps. As I stated 
earlier, I'm not changing the buffering scheme itself. However, the 
buffer durations and rates are exposed by properties now. So, if you had 
enough memory, you could increase the buffer sizes or change their rates.

cheers,
Thorsten

--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] flight recorder / replay system

2011-09-05 Thread ThorstenB
On 05.09.2011 21:00, Curtis Olson wrote:
 While you have your head under the replay hood;  Originally the replay
 system did not record itself replaying a flight, but along the way, a
 subtle code change messed this up so we recorded our replay as if it was
 a live flight.  This led to an endless playback loop where we'd replay a
 replay of our replay (for as many times as we let it run.)

Hmm,  I've been using the replay system quite often recently. Not seen 
any such issue. And I'm quite sure the recorder (even for FG2.4.0) is 
sane and doesn't record during playback.
Are you sure the issue you're seeing isn't just the loop feature? 
Check the instant replay dialog. Default setting is looped playback, 
so the most recent 90 seconds are replayed continuously. You can change 
the setting and change the loop duration to 3600 seconds (1h), so you'll 
always see the full (available) recording. Or you could disable the 
continuous loop altogether...

Anyway, with the new video player-like dialog, the behaviour of the 
replay feature should be much easier to handle.

cheers,
Thorsten

--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] RE : Cmake

2011-09-05 Thread Frederic Bouvier
Alan,

Your bad experience is not a generality. All you have to do is set the 
MSVC_3RDPARTY_DIR and hit configure again, and all the other directories should 
be set automatically.

Regards,
-Fred

Alan Teeder ajtee...@v-twin.org.uk a écrit :

-Original Message- 
From: MathiasFröhlich
Sent: Monday, September 05, 2011 4:28 PM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Cmake


Hi,

On Monday, September 05, 2011 14:47:44 Alan Teeder wrote:
 Please don´t.

 I reverted from VC100 to VC90 as the Cmake process was always failing.
 There is a difference between Hudson saying that all is OK with Cmake and
 Visual Studio VC100 producing working executables.

 This was all with the de-facto standard 3rd party package from
 ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/.

 I could get the system to work, but then it would all go wrong after a few
 days or weeks. On the other hand the current VC90 project files seem quite
 robust.

Then please tell what is going wrong.
This is like every piece of code lingering around in this and similar
projects. The people doing the changes do their best to make it work. But if
there is something failing on some other platform/configuration/... feedback 
is
needed.

Thanks

Mathias
---
Mathias

I did, but I am afraid that your reply did not address my question.

When I did get it working, every time that there was a change requiring a 
new set of project files, Cmake got very confused and came up with new sets 
of problems.

Each time that I deleted the cache (to start afresh when cmake gave up), 
cmake wanted loads of info, most of which it should have known as my 
flightgear folder layout is the standard one.  Boringly,  I had to re-enter 
the location of every simgear library, as well as openal and zlib which 
already existed in the 3rd party structure.

A few more hiccups, which I can no longer remember, VS  produced  an 
executable  However this would not run and usually involved using the 
depends tool to work out why FG had been made with the wrong set of 
libraries.

The final straw came with the incorporation of HLA, which I never sorted 
out.

VC100 is to be avoided like the plague. It even seems to have problems 
linking with libraries produced with different versions of VC100.

Alan 


--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] The future of FlightGear's support programs

2011-09-05 Thread Peter Sadrozinski
Actually, I'm going to continue using my parser for now.  It looks like
there are still some bugs in the ogr2ogr importer with respect to closing
polys with curves.

Here's an image showing some of the polys being closed with linear segments
instead of bezier.

http://dl.dropbox.com/u/29968727/Screenshot-Quantum%20GIS%201.7.0-Wroclaw.png

I had this exact same issue with my parser for a while, I'll look at the ogr
importer to see if I can submit a fix.

This image shows a different issue, which I have not seen with my parser.

http://dl.dropbox.com/u/29968727/Screenshot-Quantum%20GIS%201.7.0-Wroclaw-1.png

The poly holes should be circular, and it looks like there's an extra line
being added.  Not sure if this is something similar to the above or not.

Another reason we may wish to stay with my parser is that it offers a bit
more flexibility.  I plan on allowing options to set how many segments to
break curves into, (and possibly using more segments for curvier sections
than straighter sections)  to try to optimize for the number of polys.  I
didn't see any way to pass parameters to the ogr2ogr importer

Pete

On Mon, Sep 5, 2011 at 8:32 AM, Peter Sadrozinski psadrozin...@gmail.comwrote:

 Sigh, it's true.  I became aware of the OGR frontend just as the parser was
 being completed :(  Nothing like a good programming exercise to become
 familiar with the code, though, so all is not lost.
 I will refocus my efforts to use ogr shapefiles instead of my custom data
 structures internally.  As mentioned, we still need to generate the airport
 area holes, and the .btg file for the airport itself.  I noticed some GRASS
 modules being added to terragear-cs a few months ago, and what looked like a
 skeleton for a btg file exporter.  Is anyone actively working on this?  If
 not, I can continue down that path.

 I see qgis can only use grass modules  if QGIS was started from a GRASS
 shell or if a GRASS mapset was opened from QGIS.  Otherwise, we will need
 both a grass module and a qgis plug-in.  I imagine both will be able to
 share most of the code.

 I'd really like to be able to add something of use to the project, as I
 really enjoy flightgear.  In the past couple of years, there have been so
 many new improvements to so many systems, yet the scenery / terrain still
 seems to get the least attention (no fault on any of the developers, I just
 think it's the most intimidating piece of the project)  A one step at a time
 approach is certainly necessary, and the 8.50 airport format looked like the
 most achievable target.

 Feel free to ping me on any item you feel is needed, but don't have time
 for.  I can generally dedicate ~8-10 hours a week (especially heading into
 winter)

 Pete


 On Sun, Sep 4, 2011 at 6:20 PM, Martin Spott martin.sp...@mgras.netwrote:

 HB-GRAL wrote:

  To get XPlane gpl airport data into a postgres/postgis database as ESRI
  shapes you can use the ogr2ogr gdal plugin written by Robin Peel [...]

  s/Robin Peel/Even Rouault/

 I know because we've been exchanging a couple of EMails over the past
 three
 years while chasing a few bugs in his implementation  ;-)

 BTW, I'm really wondering why this forum user Psadro decided to invent
 his
 own v8.50 apt.dat-parser because, according to his explanations, he's
 doing
 exactly what's already implemented in the corresponding OGR-frontend.

 Cheers,
Martin.
 --
  Unix _IS_ user friendly - it's just selective about who its friends are !
 --


 --
 Special Offer -- Download ArcSight Logger for FREE!
 Finally, a world-class log management solution at an even better
 price-free! And you'll get a free Love Thy Logs t-shirt when you
 download Logger. Secure your free ArcSight Logger TODAY!
 http://p.sf.net/sfu/arcsisghtdev2dev
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel



--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] The future of FlightGear's support programs

2011-09-05 Thread Martin Spott
Hi Peter, glad to meet you here !

Peter Sadrozinski wrote:

 Another reason we may wish to stay with my parser is that it offers a bit
 more flexibility.  I plan on allowing options to set how many segments to
 break curves into, (and possibly using more segments for curvier sections
 than straighter sections)  to try to optimize for the number of polys.  I
 didn't see any way to pass parameters to the ogr2ogr importer

When you're getting in contact with Even, why not suggest this feature to
him.  As far as I remember this would be quite easy an option to add to the
OGR X-Plane parser and, according to my own experience, Even is well open to
suggestions - as well as bug reports and fixes.

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] The future of FlightGear's support programs

2011-09-05 Thread Martin Spott
Peter Sadrozinski wrote:

 I have some experience writing GRASS modules, and I noticed some were being
 added to terragear-cs a few months ago. one of which looked like a skeleton
 for a btg file exporter.  Is anyone actively working on this?  If not, I can
 continue down that path.

You're welcome to do so.

All the 'real' GRASS modules in terragear-cs's gismodules
subdirectory had been written by Ralf Gerlich, who recently left the
scene for a really convincing reason.  The other GRASS-related part
(gisscripts) consist of prototype-scripts making use of GRASS for
topologically cleaning and maintaining polygon land cover data at large
(worldwide) scale.  That's my role in the game.
As a side-effect of my experiments, the GRASS vector data model has
already seen huge improvement, but there are still a few issues to be
solved until I'd recommend the procedure for unattended use.

In fact, while spending most of my FlightGear-related spare time budget
on doing ground-work for building better FlightGear Scenery, basically
I'm (beta-)testing and exploring corner cases of the use of GRASS on
large vector databases  :-)

 I see qgis can only use grass modules  if QGIS was started from a GRASS
 shell or if a GRASS mapset was opened from QGIS.

Indeed, using GRASS plugins in QGIS just means to use QGIS as a GUI on top
of a GRASS backend as an alternative to GRASS' native GUI, they won't share
any data.

 I'd really like to be able to add something of use to the project, as I
 really enjoy flightgear.  In the past couple of years, there have been so
 many new improvements to so many systems, yet the scenery / terrain still
 seems to get the least attention (no fault on any of the developers, I just
 think it's the most intimidating piece of the project)

I think what you're looking at is a clash between two fundamentally
different ways of understanding the term developing scenery  :-)

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Cmake

2011-09-05 Thread James Turner

On 5 Sep 2011, at 17:10, Curtis Olson wrote:

 So I have nothing against cmake, it sounds like it offers some nice features. 
  But I assume those that want to push this change forward, will take some 
 time to write up some basic howto's so that people who have never used it as 
 a developer can get up to speed without too many problems?
 
 Right now when I poke around on the wiki and I'm sure the getstart manual, 
 all the instructions are automake based.  Hopefully  we can do some proactive 
 hunting of automake references in our instructions scattered around and get 
 those cleaned up in advance?

 Are there any cmake based build instructions available anywhere?  I'm not 
 seeing them.

Yes, absolutely - Brisa's helper script also needs to be updated. We're at the 
start of that process now, but I don't want to document things if they are 
about to change, which brings me too:

 
 When building OSG, you run ./configure; make; make install like any other 
 project.  However, ./configure is an automake/conf generated in flightgear.  
 For a cmake dummy, how do you even go about building flightgear with cmake?  
 (I of course know everything, but I do have a friend who's a little 
 inexperienced with cmake.)

OSG supply a 'configure' script for sue with Cmake, and we can do the same, to 
keep things more familiar for people. I'll look into borrowing the CMake one :)

 Is there a way to do the equivalent of make dist in cmake to generate 
 .tar.gz source releases?  Has this been tested to see if it includes all the 
 necessary files?

That's what CPack does - I've tested tar.gz creation, and there is some 
supported for Slackware  TGZ / .deb / .rpm creation too. I'm sure the rules 
need some improvement to catch all the docs / utils / data files that the 
current make dist captures.

 We have some extra automake rules to help create the data archives (which is 
 important because this officially defines what goes into the release 
 installer for both Mac and Windows as well as the data archive for people 
 building from source code (who aren't doing 3Gb of git for the data tree.))

Indeed! 

 I'm just hoping the cmake jocks will put themselves in the position of 
 non-cmake jocks and help ease the transition from multiple fronts for many of 
 our different classes of users/developers.

Yes absolutely, and feedback (like above) is the driver for that.

james

--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] ATC and radio signal attenuation

2011-09-05 Thread Martin Spott
Adrian Musceac wrote:

 I have started to implement radio signal attenuation into the ATC subsystem, 
 with the goal to later move this to it's own location.

I'm pretty certain that future will show us many possible uses for a generic
implementation (just think of FGCom).  Nice to hear about it,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel