Re: [Flightgear-devel] memory hemorrhage

[Tim Moore]

On Fri, Feb 5, 2010 at 7:30 AM, Heiko Schulz aeitsch...@yahoo.de wrote:

 Hi
 
  I don't see any new sceneries which are
  clobbered.
 
 
  You yourself said in another
  email:
  -Framerates in KSFO 28R less than used to. Usually I
  get up to 60 fps
  with everything enabled in FGFS, but throttled it down to
  30.
 
  In KSFO I now get 25 fps with the 777-200, other aircrafts
  are better.
 
 
 Maybe misunderstood: my dictionaries gives for clobbered something like
 hit, beaten.

 So can you tell us what you exactly mean with?

That's the correct definition. I meant that the frame rate was clobbered.
Perhaps clobbered is a bit strong.

Tim
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Inconsistencies in nav.dat.gz and apt.dat.gz

[Martin Spott]

Jari Häkkinen wrote:

 Maybe the issues described above are valid only for my local build
 [...]

You might check if things look differently when using a build from
current CVS,

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

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] memory hemorrhage

[Tim Moore]

On Thu, Feb 4, 2010 at 12:03 PM, Martin Spott martin.sp...@mgras.netwrote:

 Hi Tim,

 Tim Moore wrote:

  I haven't looked at NYC in a while, but our urban areas tend to get
  clobbered, particularly when the scenery guys strut their stuff for a new
  release.

 The vast majority of the changes I've recently pushed to the Base
 Backage CVS had either been moving/sorting files between directories or
 updating files in order to reflect the past ambient colour change. Very
 few 'new' files have been added, mostly lightweight stuff and, as far
 as I remember, none of these affect the NYC area.

I'm referring here to KSFO, and the only change I can point to is that new
KSFO scenery is now in the base package. I tend to be lazy and use that for
most of my testing.


 BTW, even the forementioned 'new' stuff has been around on the usual
 download locations either at http://scenemodels.flightgear.org/; or
 via TerraSync (the NYC Scenery hasn't been part of the Base Package
 anyway). Therefore I'm unable to identify a reasonable cause why recent
 changes from the Scenery department should be having a noticeable
 impact in terms of runtime performance, you might have to go finding
 another culprit  :-)

 See above. I do need to get with program in terms of using the latest
product of the scenery team.


  The ideal would be to coalesce all the buildings in a city block into one
  model with one texture.

 We're doing our best to prevent this 

Teutonic irony, I hope :)

 Actually one could think of adding a preprocessing stage between the
 'raw' ressources (Terrain and AC3D models) and the FlightGear runtime
 environment by collapsing 1x1 degree or smaller area tiles into a
 single Scenery file of a format to be choosen, but as long as
 Sim-/FlightGear doesn't provide the infrastructure to deal with this
 flavour of Scenery (including all the animation stuff and the like), I
 don't see us getting there too soon.

Perhaps we need an .stg / .btg summit to hash out some changes like this.

By the way, the new hotness in terrain visualization seems to be creating
buildings from shape files that encode the height of each building, with a
big texture (extracted from a bigger image) that has an image of each roof.
If you assume that buildings are prisms, an efficient representation of the
building polygons can be created at load time. Any thoughts on that
approach?

Tim
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] memory hemorrhage

[Jon Stockill]

Tim Moore wrote:

 By the way, the new hotness in terrain visualization seems to be 
 creating buildings from shape files that encode the height of each 
 building, with a big texture (extracted from a bigger image) that has an 
 image of each roof. If you assume that buildings are prisms, an 
 efficient representation of the building polygons can be created at load 
 time. Any thoughts on that approach?

Not done at runtime, and untextured but:

http://gallery.flightgear.org.uk/c1702623.html

Ok for basic buildings, but our modellers can do much better. Its a 
handy technique for filling in buildings, but you have to be careful 
just how many you create - those examples resulted in 1fps.

Jon

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Inconsistencies in nav.dat.gz and apt.dat.gz

[Jari Häkkinen]

Ok, so this really bounces to Tat. Tat, the flightgear source you use is 
based on what's in git ... looking into 
fg/source/src/Navaids/navrecord.cxx reveals that the CVS version has 
some more control code that avoid the issues I reported in this thread. 
Tat, can you look into this?

Martin, thanks for the pointer.


Still, the inconsitencies remain but that maybe is okay?


Jari


On 2/5/10 11:53 AM, Martin Spott wrote:
 Jari Häkkinen wrote:

 Maybe the issues described above are valid only for my local build
 [...]

 You might check if things look differently when using a build from
 current CVS,

   Martin.


--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] memory hemorrhage

[Heiko Schulz]

Hi
 
 That's the correct definition. I
 meant that the frame rate was clobbered. Perhaps
 clobbered is a bit strong. 
 Tim
 

This gives far more sense then.

For KSFO it would maybe help to change the power pylons. Currently it is one 
sized .ac-model but which is changed in size per scale-animation in .xml.
As we already know every used .xml will slow down, so a big amount of .xml in a 
scenery can be deadly (like Paris-scenery)

Problem: I don't think to replace all power pylons is an easy task

Cheers
HHS

__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com 

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] 747-400

[Gijs de Rooy]

Hi,

 Just wanted to know if anybody was working on it so I don't duplicate wnat 
 other people are doing.
 Do I understand correctly you are doing a 3D model and such of a 747?.If so I 
 won't bother with the
 current 747-400

Most of it is already in CVS for quite a while. Under Aircraft/747-400 (the 
Pakistan/old 747 is under 
Aircraft/747). 
Progress is slow, but every now and then I am able to finish something. Some 
things are not in CVS due
to the hard-to-commit-way I have to follow so far... 

 

Help (on various parts, from model to AP to FDM) is always apreciated ofcourse 
;)

 

Regards,

Gijs

  
_
Het laatste nieuws, shownieuws en voetbalnieuws op MSN.nl
http://nl.msn.com/--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] memory hemorrhage

[Jon Stockill]

Heiko Schulz wrote:
 Hi
 That's the correct definition. I
 meant that the frame rate was clobbered. Perhaps
 clobbered is a bit strong. 
 Tim

 
 This gives far more sense then.
 
 For KSFO it would maybe help to change the power pylons. Currently it is one 
 sized .ac-model but which is changed in size per scale-animation in .xml.
 As we already know every used .xml will slow down, so a big amount of .xml in 
 a scenery can be deadly (like Paris-scenery)
 
 Problem: I don't think to replace all power pylons is an easy task

Actually, it's a very easy task :-)

Jon

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] memory hemorrhage

[Martin Spott]

Heiko Schulz wrote:

 For KSFO it would maybe help to change the power pylons. Currently it
 is one sized .ac-model but which is changed in size per
 scale-animation in .xml.
 As we already know every used .xml will slow down, so a big amount of
 .xml in a scenery can be deadly (like Paris-scenery)

I understand your conclusion. Nevertheless from a policy point of view,
as long as these 'gadgets' like animations (or scripting, whatever) are
available for use, it'll be hard to educate modellers not to use them.

If efficient handling of the features as offered in this API is
impossible, then I'd say the appropriate measure would be to reduce the
scope of the API and to communicate this change accordingly.

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

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Some quirks in various Aircraft

[bitwPolly]

Thank you for the fixes and for the super models. I noticed a couple of  
things in the Primus1000:

Aircraft/Instruments-3d/primus-1000/P1000.nas
   At present, at startup, hitting NAV gumdrop button alternates NAV1/NAV2  
pointers but, after hitting FMS button, the pointers will
not revert to NAV modes. To unstick 'FMS' mode:
  P1000.nas copy line 238:  
me.NavString.setValue(me.NAV_SRC[me.NavType.getValue()]);
   after line 229:  to reset the string Value in the NAV stanza
   Ater new line 230 add to read:

 elsif(dc==nav)
 {
 var nv = me.ctl_nav.getValue();
 nv= 1- nv;
 me.ctl_nav.setValue(nv);
 me.ctl_fms.setBoolValue(0);
 me.fms_mode.setValue(me.FMS_VNAV[0]);
 if(getprop(instrumentation/nav[~nv~]/has-gs)){
 me.NavType.setValue(2 + nv);
 }else{
 me.NavType.setValue(0 + nv);
 }
 me.NavString.setValue(me.NAV_SRC[me.NavType.getValue()]);
 me.update_pfd();
 }
 elsif(dc==fms)
 {
 if(getprop(autopilot/route-manager/route/num)  0){
 me.ctl_fms.setBoolValue(1);
 me.NavType.setValue(4);
 me.fms_mode.setValue(me.FMS_VNAV[1]);
 }
 me.NavString.setValue(me.NAV_SRC[me.NavType.getValue()]);
 me.update_pfd();
 }
So that the mfd NAV pointers react properly to new settings

Aircraft/Instruments-3d/primus-1000/PFD/pfd1.png
   The uppermost compass rose has, in the 060 degree position, a numeral  
'5' , it should be a '6' .
It shows when the HSI is selected for 'big rose'

Thanks again,
Rgds
-- 
=

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] 747-400

[Pete Morgan]

Gijs, why not just create a clone of 747 series in github, or gitorious 
, and then that can be merges into CVS later maybe.

pete

Gijs de Rooy wrote:
 Hi,

  Just wanted to know if anybody was working on it so I don't 
 duplicate wnat other people are doing.
  Do I understand correctly you are doing a 3D model and such of a 
 747?.If so I won't bother with the
  current 747-400

 Most of it is already in CVS for quite a while. Under Aircraft/747-400 
 (the Pakistan/old 747 is under
 Aircraft/747).
 Progress is slow, but every now and then I am able to finish 
 something. Some things are not in CVS due
 to the hard-to-commit-way I have to follow so far... 
  
 Help (on various parts, from model to AP to FDM) is always apreciated 
 ofcourse ;)
  
 Regards,
 Gijs


 
 Voeg je Hyves, Facebook en LinkedIn contacten toe aan Hotmail en 
 Messenger 
 http://www.microsoft.com/netherlands/windowslive/Views/productDetail.aspx?product=Photos
  

 

 --
 The Planet: dedicated and managed hosting, cloud storage, colocation
 Stay online with enterprise data centers and the best network in the business
 Choose flexible plans and management services without long-term contracts
 Personal 24x7 support from experience hosting pros just a phone call away.
 http://p.sf.net/sfu/theplanet-com
 

 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   


--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] configuration info

[Geoff McLane]

Hi Jari,

I read _LOUDLY_ your 'fear' that changing anything
to do with the 'svn' may cause some unwanted
change... but feel this is totally unfounded...

It seems my explanation that changing -
AC_CHECK_HEADERS([svn_client.h glut.h])
- to -
AC_CHECK_HEADERS([svn_client.h])
would change NOTHING about the test for
'svn_client.h' yes/no FAILED to get through...

You need to carefully check the references of
AC_CHECK_HEADERS([header-file-list]
  [, action-if-found 
  [, action-if-not-found]])
to SEE that the 'header-file-list' are EACH treated
completely separately. They would 'share' the
'action-if-found', and 'action-if-not-found' if
any were given, but in this case the default
actions are used, so are separate...

It is _NOT_ a case of if one fails, they all fail.
As stated, if you had looked in the config.log, you
would see that each test is done independently of 
the results of any previous test in the 'list'...

That is the test, as is, would generate BOTH -
1. $ac_cv_header_svn_client_h = yes|no
2. $ac_cv_header_glut_h = yes|no

But I have had more time to write, and test a
BETTER patch attached that :-
(a) does NOT change the svn_client.h lines ;=((,
(b) avoids having to change tests/gl-info.cxx,
(c) now includes the different check for the MAC.

It seems that autoconf is smart enough to ignore
the 'glut.h' listed in -
AC_CHECK_HEADERS([svn_client.h glut.h])
once a specific later AC_CHECK_HEADERS([GL/glut.h],...
is given, that contains an 'action-if-found' ;=() so I 
leave that line UNCHANGED, and only add this new
check...

And if you have removed all glut.h tests in your
local configure.ac, then that is fine. It certainly
means your tests/gl-info will also fail unless
your GLUT/glut.h defines HAVE_GLUT_H... as
would tests/test-env-map.cxx... 

And I hope your other 'svn' changes also make it
into CVS...

You had a hand in changing this 1998 Steve Baker
file from .c to .cxx just recently, probably to
get it to compile in the MAC. And at that time this
'HAVE_GLUT_H' was added - by Erik? 

Likewise to tests/test-env-map.cxx...

I note the ONLY other file in the source
that calls glutInit() is 
utils/Modeller/3dconvert.cxx
and it has been commented out of the Makefile.am!

So indeed another option is to REMOVE gl-info.cxx
AND test-env-map.cxx from the compile (the 
Makefile.am), like 3dconvert.cxx... 

A grep for glutInit seems to indicate these are
the ONLY 3 files in the FG source that still use
glutInit...

I would prefer my nice patch, but since fgfs no
longer uses glut, maybe the REMOVE option is
best ;=))

Of course there is SG -
simgear/source/simgear/screen/TestRenderTexture.cpp
which I had a hand in modifying relatively recently
to compile and run in WIN32, and it has no
protective #ifdef HAVE_GLUT_H, or HAVE_GL_GLUT_H...
and thus the SG configure.ac does NOT contain a
GL/glut.h, nor GLUT/glut.h, test...

To be clear this is NOTHING about 'svn', and will
NOT effect anything related to how 'svn' is
compiled into fgfs for terrasync use...

It is about, as the subject states, providing
'good' configuration information only...

HTH, and NOT cause further confusion ;=))

Regards,

Geoff.

attached: fg200-diff02.patch


On Thu, 2010-02-04 at 20:17 +0100, Jari Häkkinen wrote:
 On 2/4/10 6:16 PM, Geoff McLane wrote:
  Hi Jari,
 
  HOW?
 
 I have nothing against your patch, actually I have thrown away the check 
 for glut.h completely in my local configure.ac. The check for glut.h is 
 not needed. On my machine (Mac OS X 10.6) the
 
 AC_CHECK_HEADERS([svn_client.h glut.h])
 
 always fail and in consequence the failure will trigger command line use 
 in terrasync as stated in configure.ac after the AC_CHECK_HEADERS
 
 if test x$ac_cv_header_svn_client_h != xyes; then
echo TerraSync will shell out for command line subversion
svn_LIBS=
svn_CPPFLAGS=
 else
 ...
 
 While I am writing this I realize that one of course need development 
 libs for svn to pass the AC_CHECK_HEADERS so I suppose my statement was 
 not perfectly accurate. I have the devlibs for svn installed and I 
 actually go further in my local change of configure.ac and look for 
 several svn libs:
 
 ...
   else
 echo TerraSync will use integrated subversion library
 AC_SEARCH_LIBS(svn_client_checkout, svn_client-1)
 +  AC_SEARCH_LIBS(svn_delta_version, svn_delta-1)
 +  AC_SEARCH_LIBS(svn_diff_version, svn_diff-1)
 +  AC_SEARCH_LIBS(svn_ra_initialize, svn_ra-1)
 +  AC_SEARCH_LIBS(svn_pool_create_ex, svn_subr-1)
 +  AC_SEARCH_LIBS(svn_wc_version, svn_wc-1)
 svn_LIBS=$LIBS
 svn_CPPFLAGS=$CPPFLAGS
 AC_SUBST(svn_LIBS)
 
 and build a terrasync with builtin subversion calls. This is not really 
 a good thing since terrasync with builtin subversion calls behaves badly 
 when terrasync is interrupted during subversion calls. An issue 
 acknowledge by Alex Perry in 
 http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25662.html
 
 Again, the patch is valid I just wanted to highlight the fact that it 
 

[Flightgear-devel] surprising command-line feature

[John Denker]

One of my students recently typed the command
  fgfs : echo $?

The result was:
Fatal error: Failed to open file
 at :
 (received from SimGear XML Parser)

--

Two observations:
  1) The student found this error message to be uninformative.
   I have to agree;  using the word at for this purpose seems 
   non-standard and confusing.  Attached is a patch to make
   several improvements in the error message.

  2) Why is fgfs trying to open a file?  Is this an important
   feature?  What might be the semantics of this feature?

   I couldn't find it documented anywhere in getstart.pdf or
   in the --help --verbose message.













commit 3a4e6c2177b05ac14002e6795abaa6c5582c31c8
Author: John Denker j...@av8n.com
Date:   Fri Feb 5 08:50:09 2010 -0700

More informative error message.

diff --git a/simgear/structure/exception.cxx b/simgear/structure/exception.cxx
index accd970..2bea8d1 100644
--- a/simgear/structure/exception.cxx
+++ b/simgear/structure/exception.cxx
@@ -102,12 +102,12 @@ sg_location::asString () const
 {
   std::ostringstream out;
   if (_path[0]) {
-out  _path;
+out  '  _path  ';
 if (_line != -1 || _column != -1)
   out  ,\n;
   }
   if (_line != -1) {
-out  line   _line;
+out   at line   _line;
 if (_column != -1)
   out  , ;
   }
@@ -270,8 +270,7 @@ sg_io_exception::getFormattedMessage () const
   string ret = getMessage();
   string loc = getLocation().asString();
   if (loc.length()) {
-ret += \n at ;
-ret += loc;
+ret += \n File:  + loc;
   }
   return ret;
 }


--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] configuration info

[Jari Häkkinen]

On 2/5/10 4:04 PM, Geoff McLane wrote:
 Hi Jari,

 I read _LOUDLY_ your 'fear' that changing anything
 to do with the 'svn' may cause some unwanted
 change... but feel this is totally unfounded...

Yes, I agree. My bad. I added your checks to my configure.ac.


Jari

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] configuration info (svn part)

[Jari Häkkinen]

On 2/5/10 4:04 PM, Geoff McLane wrote:

But I have had more time to write, and test a
BETTER patch attached that :-
(a) does NOT change the svn_client.h lines ;=((,


(a) should be changed, I agree with your original proposal.

Actually I think subversion support in terrasync should be removed 
altogether or fixed. If removed then all svn checks could be removed.




And I hope your other 'svn' changes also make it
into CVS...


I attach my suggested svn related changes to configure.ac for reference 
for other new builders of fg. Note, apply the patch cautiously since 
having svn calls in terrasync may lock the terrasync-WC directories in 
some cases (with fairly high probability).


Maybe there should be a check for APR but I suppose that if svn-devel 
package are installed then also apr will be available.



Geoff, how do you make it through the svn check in configure.ac or 
really building terrasync?



Jari
Index: configure.ac
===
RCS file: /var/cvs/FlightGear-0.9/source/configure.ac,v
retrieving revision 1.166
diff -u -p -r1.166 configure.ac
--- configure.ac5 Feb 2010 05:40:15 -   1.166
+++ configure.ac5 Feb 2010 16:40:26 -
@@ -787,10 +803,9 @@ fi
 dnl Check for Subversion library support
 save_LIBS=$LIBS
 save_CPPFLAGS=$CPPFLAGS
-LIBS=
+LIBS=`apr-1-config --link-ld`
 CPPFLAGS=-I/usr/include/subversion-1 `apr-1-config --includes`
-AC_CHECK_LIB(svn_client-1, svn_client_checkout3)
-AC_CHECK_HEADERS([svn_client.h glut.h])
+AC_CHECK_HEADERS([svn_client.h])
 if test x$ac_cv_header_svn_client_h != xyes; then
   echo TerraSync will shell out for command line subversion
   svn_LIBS=
@@ -798,6 +813,11 @@ if test x$ac_cv_header_svn_client_h !=
 else
   echo TerraSync will use integrated subversion library
   AC_SEARCH_LIBS(svn_client_checkout, svn_client-1)
+  AC_SEARCH_LIBS(svn_delta_version, svn_delta-1)
+  AC_SEARCH_LIBS(svn_diff_version, svn_diff-1)
+  AC_SEARCH_LIBS(svn_ra_initialize, svn_ra-1)
+  AC_SEARCH_LIBS(svn_pool_create_ex, svn_subr-1)
+  AC_SEARCH_LIBS(svn_wc_version, svn_wc-1)
   svn_LIBS=$LIBS
   svn_CPPFLAGS=$CPPFLAGS
   AC_SUBST(svn_LIBS)
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] configuration snafu

[John Denker]

I'm glad to see people are cleaning up the autoconf stuff.

Here's yet another area that needs some TLC:  There appears 
to be little or no chance that the autoconf system will do 
the right thing on 64-bit machines.

I'm hoping this will be easy for some autoconf guru to fix.
I would imagine there are well-known standard techniques
for coping with lib/lib64 issues.

This is currently item #45 on this list of bugs:
  http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit


--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] [patch] Write pid into property tree and optionally into a file.

[John Denker]

Two closely-related new features:
  property: /sim/pid
  option:   --pid=/pathto/some/file.pid

Having the pid available is useful for many purposes,
including sending a signal for debugging.

Somebody should please check that this works under MSVC.
It looks to me like pretty standard c++ but it's still
good to check.


commit cc188f7499c03417b1d4a3cb296702ba7b4d67fa
Author: John Denker j...@av8n.com
Date:   Fri Feb 5 10:12:15 2010 -0700

Write pid into property tree and optionally into a file.

diff --git a/src/Main/main.cxx b/src/Main/main.cxx
index d5ac553..38202e4 100644
--- a/src/Main/main.cxx
+++ b/src/Main/main.cxx
@@ -885,6 +885,7 @@ bool fgMainInit( int argc, char **argv ) {
 upper_case_property(/sim/presets/runway);
 upper_case_property(/sim/tower/airport-id);
 upper_case_property(/autopilot/route-manager/input);
+fgSetInt (/sim/pid, getpid() );
 
 // Scan the config file(s) and command line options to see if
 // fg_root was specified (ignore all other options for now)
diff --git a/src/Main/options.cxx b/src/Main/options.cxx
index 3b4354f..9eb41b5 100644
--- a/src/Main/options.cxx
+++ b/src/Main/options.cxx
@@ -39,6 +39,7 @@
 #include string.h// strcmp()
 #include algorithm
 
+#include fstream  /* ofstream */
 #include iostream
 #include string
 
@@ -1234,7 +1235,20 @@ fgOptFgviewer(const char* arg)
 return FG_OPTIONS_OK;
 }
 
-
+static int
+fgOptPid(const char* arg)
+{
+pid_t pid = getpid();
+ofstream out;
+out.open(arg, ofstream::out);
+out  pid  endl;
+out.close();
+if (!out.good()) {
+   SG_LOG(SG_GENERAL, SG_ALERT,
+  Unable to write pid (  pid 
+   ) to file '  arg  ');
+}
+}
 
 static mapstring,size_t fgOptionMap;
 
@@ -1449,6 +1463,7 @@ struct OptionDesc {
 {version,  false, OPTION_FUNC,   , false, , 
fgOptVersion },
 {enable-fpe,  false, OPTION_FUNC,   , false, , 
fgOptFpe},
 {fgviewer,false, OPTION_FUNC,   , false, , 
fgOptFgviewer},
+{pid,  true, OPTION_FUNC,   , false, , 
fgOptPid },
 {0}
 };
 

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] configuration info (svn part)

[Martin Spott]

Jari Häkkinen wrote:

 Actually I think subversion support in terrasync should be removed 
 altogether or fixed. If removed then all svn checks could be removed.

Oh my, could you _please_ stop this litany ? One posting of this sort
per day should really be enough, two or more are a nuisance. According
to my experience you're trying to make people throw the baby out with
the bath water, which is not appropriate here.

If we were to drop every feature which _might_ occasionally have a
malfunction here or there, then we would end up with having no
FlightGear at all,

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

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Feedback ReleaseCandidate4

[James Turner]

I'm stuck up an Alp until Monday, but the AB is likely just the  
autopilot Xml entry being accidently removed - I shall check upon my  
return to reality.

As for the GPS, please do ask if things seem strange, I'm happy to  
make code changes, or document things better. The departure waypoint  
exists so there is 'always' a previous waypoint - it should never  
normally be the active waypoint, though likely this is possible in  
some edge cases of deleting waypoints.

James

On 5 Feb 2010, at 01:46, syd adams adams@gmail.com wrote:

 777-200: Heading hold doesn't work properly. The aircraft is  
 oscillating from one side to the other. That didn't appear 2-3 weeks  
 before.
 -Oscillating from one side to the other when NAV-1-GS-hold captured.
 That didn't appear 2-3 weeks before.
 -new Autobrakes system don't work

  Im so happy to hear the news that I think I'll celebrate tonight :)

 Im still tweaking , but keep getting pull off in different  
 directions  and I do see this behavior
 now on approach . sigh

 The Autobrake was James addition , and I haven't had time to go over  
 it. Still trying to sort out the gps changes first (which I think Im  
 finally getting, although Im still puzzled about the departure point  
 being used as a waypoint ).

 If you feel like tackling these issue's , feel free. Personally , I  
 dont think it should be necessary  to add
 dozens of filter's to get good behavior , but maybe I'm wrong there.

 Cheers


 --- 
 --- 
 --- 
 -
 The Planet: dedicated and managed hosting, cloud storage, colocation
 Stay online with enterprise data centers and the best network in the  
 business
 Choose flexible plans and management services without long-term  
 contracts
 Personal 24x7 support from experience hosting pros just a phone call  
 away.
 http://p.sf.net/sfu/theplanet-com
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [patch] 787-set.xml

[YOSHIMATSU Toshihide]

Hi Curt,

I quickly saw forum posts about some new 787 aircrafts:
http://www.flightgear.org/forums/viewtopic.php?f=4t=5207.

But I couldn't realize which files should be (or planed to be)
committed to CVS.

So, would you please simply delete the following line in
data/Aircraft/787/787-set.xml in cvs?

aircraft-version02_2008/aircraft-version

Otherwise, your admin/make-aircraft-html.pl will not include 787 in
downloads/aircraft/index.shtml.


Cheers,
Toshi

From: YOSHIMATSU Toshihide qzt04...@nifty.ne.jp
Subject: [Flightgear-devel] [patch] 787-set.xml
Date: Wed, 06 Jan 2010 00:18:03 +0900 (JST)

 Hi all,
 
 As you may know, 787 aircraft has been disappeared from official
 aircraft download page.
 
 cf.
 http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21552.html
 
 To include the 787 on download page at the next release timing, I'll
 send a simple patch for 787-set.xml.
 
 This patch will also have an effect to prevent to become the same file
 name of 787_02_2008.zip with different contents, which were
 committed to cvs after Dec. 2008.
 
 
 Cheers,
 Toshi
 
 
 Index: 787-set.xml
 ===
 RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/787/787-set.xml,v
 retrieving revision 1.9
 diff -u -r1.9 787-set.xml
 --- 787-set.xml   19 Dec 2008 15:23:39 -  1.9
 +++ 787-set.xml   5 Jan 2010 14:45:57 -
 @@ -3,7 +3,6 @@
  descriptionBoeing 787-8/description
  authorJoshua Wilson/author
  statusDevelopment/status
 -aircraft-version02_2008/aircraft-version
  flight-modelyasim/flight-model
  aero787/aero
  fuel-fraction0.10/fuel-fraction
 
 
 --
 This SF.Net email is sponsored by the Verizon Developer Community
 Take advantage of Verizon's best-in-class app development support
 A streamlined, 14 day to market process makes app distribution fast and easy
 Join now and get one step closer to millions of Verizon customers
 http://p.sf.net/sfu/verizon-dev2dev 
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] configuration info (svn part)

[Martin Spott]

Martin Spott wrote:

 Oh my, could you _please_ stop this litany ? One posting of this sort
 per day should really be enough, two or more are a nuisance. According
 to my experience you're trying to make people throw the baby out with
 the bath water, which is not appropriate here.

  which, BTW, doesn't mean that I'm against having a fix to clean
up open connections and/or pending SVN locks,

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

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Feedback ReleaseCandidate4

[Heiko Schulz]

Hi,

 I'm stuck up an Alp until Monday, but
 the AB is likely just the  
 autopilot Xml entry being accidently removed - I shall
 check upon my  
 return to reality.

Indeed it is removed, but with changing back still doesn't work. Something is 
still missing.
The same for the 747-400.
 
 As for the GPS, please do ask if things seem strange, I'm
 happy to  
 make code changes, or document things better. The departure
 waypoint  
 exists so there is 'always' a previous waypoint - it should
 never  
 normally be the active waypoint, though likely this is
 possible in  
 some edge cases of deleting waypoints.
 

@Syd: 
With your changes from today I see some other strange things now:

-VNAV only follows airports- but not any other Waypoints like VOR, NDB, 
fixes
Only when frq turned to VOR

The real behaviour should be that the AFDS follows all waypoints in FMC-Mode 
aka Route-Manger. (similar like the Citation X), otherwise it steers the 
aircraft to the station selected with the NAV-radio.  

-TO/GA-mode let the aircraft circle

Doc about the real thing: 
http://www.smartcockpit.com/pdf/plane/boeing/B777/systems/0004/

Cheers
HHS



__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com 

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] severe erosion of the terrain

[leee]

On Friday 05 Feb 2010, John Denker wrote:
 Here’s the setup: Start the program as

 fgfs  --airport=KLXV  --metar= 012345Z 0KT 99SM CLR
 15/M01 A2992

 Let the aircraft sit on the runway. There is no need to start the
 engine. Use the v key to cycle through the available views. The
 scenery looks normal until you get to the last view, i.e. the
 model view. Then you will see that most (perhaps all) of the
 terrain is gone. Normally this view would show the aircraft
 sitting on the runway, but what you get instead is shown in
 figure 2. Cycling through the other views shows that their
 terrain is now gone, too, and does not come back.
 http://www.av8n.com/fly/fgfs/htm/bug-list.htm#fig-erosion-day

 If you do it at night, you find that the entire planet has been
 eaten away; the sun and stars are visible below the horizon, as
 shown in figure 3.
 http://www.av8n.com/fly/fgfs/htm/bug-list.htm#fig-erosion-night

 This type of failure is 100% reproducible chez moi. The degree of
 failure is somewhat variable, in the sense that sometimes all the
 terrain is gone but sometimes scattered remnants can be seen.

 Sometimes if you let the aircraft sit on the eroded terrain for a
 while, it goes through its “crash” ritual, wiggling and tumbling,
 which is pretty silly given that the engine was never started.

 It is common to get segfaults. I can provide detailed logs if
 anybody is interested.

Are those clouds on the horizon or is it distant scenery?  If it's 
scenery then funnily enough, back in Feb2008, I reported a bug 
where exactly the opposite seemed to be happening i.e. the scenery 
was ok up to a radius of about 12nm around the aircraft but was 
invisible beyond that.  Where the scenery was mountainous you could 
see it gradually appearing as you flew towards it; can you see the 
distant scenery (if that is what it is) disappearing as you fly 
towards it?

If you try flying higher, can you establish whether there is indeed 
a ring of scenery around your current position?

LeeE

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] configuration info (svn part)

[Geoff McLane]

Hi Jari,

 Geoff, how do you make it through the svn check in 
 configure.ac or really building terrasync?

I don't have any problems ;=)) utils/TerraSync/
terrasync builds without ANY problems in my
64-bit Ubuntu 8.04...

I do _NOT_ have the svn library, nor svn_client.h installed,
but of course do have runtime svn version 1.5.1 (r32289),
and rsync version 3.0.4, protocol version 30, so assume 
fgfs would shell out, IF NEED BE...

But I _NEVER_ use TerraSync! It is abhorrent to me that fgfs
should need to download 'scenery' to my machine, on the
fly, as it is, putting it somewhere... UGH!

But to be sure, the concept of 'terrasyncing' is good,
for those who want to use it, and should be continued,
and fixed if there are problems, but for me, like 'real'
piloting, I prefer to make sure I have all the
maps, oops I mean scenery, BEFORE I go there ;=))

I have downloaded, and installed 100% of the current 
scenery 1.0.1, and will do the same as each new build
is done... HDD space is really cheap these days...

Or I could burn my own DVDs, or better still toss a
few bucks to Curt and get the DVD set by mail...

As simple as that ;=))

Regards,

Geoff.

PS: I hope this post is NOT classified as part
of any 'litany' ;=()



--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] severe erosion of the terrain

[John Denker]

On 02/05/2010 11:26 AM, leee wrote:

 Are those clouds on the horizon or is it distant scenery?  

Scenery.  Mountainous terrain.  Clearly recognizable as such.  

No clouds anywhere:
  METAR  012345Z 0KT 99SM CLR 15/M01 A2992

 If it's 
 scenery then funnily enough, back in Feb2008, I reported a bug 
 where exactly the opposite seemed to be happening i.e. the scenery 
 was ok up to a radius of about 12nm around the aircraft but was 
 invisible beyond that.

Was that ever reproducible?  Was a fix ever devised?

Has anybody tried to reproduce the erosion issue?  It
remains 100% reproducible chez moi.


--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] memory hemorrhage

[Martin Spott]

Tim Moore wrote:
 On Thu, Feb 4, 2010 at 12:03 PM, Martin Spott martin.sp...@mgras.netwrote:
 Tim Moore wrote:

 I'm referring here to KSFO, and the only change I can point to is that new
 KSFO scenery is now in the base package. I tend to be lazy and use that for
 most of my testing.

Ah, I see. KSFO indeed has seen a couple of late submissions. Yet I'd
be surprised if three or four additional buildings would really make
such a difference, especially since most these late additions don't
come with any XMLifiled animation.

  The ideal would be to coalesce all the buildings in a city block into one
  model with one texture.

 We're doing our best to prevent this 

 Teutonic irony, I hope :)

It depends on from which end you choose to look at the snake  :-)

First I'd say there is very little room for change on the 'backend'
side. Preserving the ability to update/fix/replace an individual
building/landmark in the Scenery (plus a few more reasons which affect
maintenance of the collection) makes us stick with individual models.
Yet I we're certainly not tied to using AC3D as a geometry file format
and XML for the animation, people are just having the habit of
submitting these for 3D models.

But there's still a long way to go until things end up being loaded
into FlightGear. Some sort of 'compiler' could be chained into the
queue, either on the Scenery distribution side, or, as another option,
integrated into FlightGear as sort of an integrated proprocessor to the
tile-loader.

 Perhaps we need an .stg / .btg summit to hash out some changes like this.

Oh yes, let's invite ourselves to Durk's home and have a nice developer
meeting  :-)

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

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Feedback ReleaseCandidate4

[syd adams]

 -VNAV only follows airports- but not any other Waypoints like VOR, NDB,
 fixes
 Only when frq turned to VOR

 VNAV shouldn't follow ANY waypoint ... so I'm assuming you mean LNAV .
If I understand Jame's gps changes ... I should be able to eliminate my
nasal routines that detect the difference and simply use the autopilot nav1
offsets for FMS and vor modes.


 -TO/GA-mode let the aircraft circle

 Doc about the real thing:
 http://www.smartcockpit.com/pdf/plane/boeing/B777/systems/0004/


Ive had those docs for quite a while --- its just a matter of getting the
chance to read them through.
I haven't been able to grow another pair of arms yet , so bear with me :)


 Cheers
 HHS

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] configuration snafu

[Curtis Olson]

I don't doubt that there could be some lib vs. lib64 inconsistencies, but
FilghtGear builds right out of the box for me on 64bit Fedora 12 ... no
hitches at all that I recall and it has done so for quite some time.

Regards,

Curt.


On Fri, Feb 5, 2010 at 11:11 AM, John Denker j...@av8n.com wrote:

 I'm glad to see people are cleaning up the autoconf stuff.

 Here's yet another area that needs some TLC:  There appears
 to be little or no chance that the autoconf system will do
 the right thing on 64-bit machines.

 I'm hoping this will be easy for some autoconf guru to fix.
 I would imagine there are well-known standard techniques
 for coping with lib/lib64 issues.

 This is currently item #45 on this list of bugs:
  http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit



 --
 The Planet: dedicated and managed hosting, cloud storage, colocation
 Stay online with enterprise data centers and the best network in the
 business
 Choose flexible plans and management services without long-term contracts
 Personal 24x7 support from experience hosting pros just a phone call away.
 http://p.sf.net/sfu/theplanet-com
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel




-- 
Curtis Olson: http://baron.flightgear.org/~curt/
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [patch] 787-set.xml

[Curtis Olson]

Hi Toshi,

I think my script will build the 787 just fine (or am I missing something?)
 I believe the reason it wasn't included automatically in the past was
because it didn't exist is CVS.

Best regards,

Curt.


On Fri, Feb 5, 2010 at 11:49 AM, YOSHIMATSU Toshihide wrote:

 Hi Curt,

 I quickly saw forum posts about some new 787 aircrafts:
 http://www.flightgear.org/forums/viewtopic.php?f=4t=5207.

 But I couldn't realize which files should be (or planed to be)
 committed to CVS.

 So, would you please simply delete the following line in
 data/Aircraft/787/787-set.xml in cvs?

 aircraft-version02_2008/aircraft-version

 Otherwise, your admin/make-aircraft-html.pl will not include 787 in
 downloads/aircraft/index.shtml.


 Cheers,
 Toshi

 From: YOSHIMATSU Toshihide qzt04...@nifty.ne.jp
 Subject: [Flightgear-devel] [patch] 787-set.xml
 Date: Wed, 06 Jan 2010 00:18:03 +0900 (JST)

  Hi all,
 
  As you may know, 787 aircraft has been disappeared from official
  aircraft download page.
 
  cf.
 
 http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21552.html
 
  To include the 787 on download page at the next release timing, I'll
  send a simple patch for 787-set.xml.
 
  This patch will also have an effect to prevent to become the same file
  name of 787_02_2008.zip with different contents, which were
  committed to cvs after Dec. 2008.
 
 
  Cheers,
  Toshi
 
 
  Index: 787-set.xml
  ===
  RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/787/787-set.xml,v
  retrieving revision 1.9
  diff -u -r1.9 787-set.xml
  --- 787-set.xml   19 Dec 2008 15:23:39 -  1.9
  +++ 787-set.xml   5 Jan 2010 14:45:57 -
  @@ -3,7 +3,6 @@
   descriptionBoeing 787-8/description
   authorJoshua Wilson/author
   statusDevelopment/status
  -aircraft-version02_2008/aircraft-version
   flight-modelyasim/flight-model
   aero787/aero
   fuel-fraction0.10/fuel-fraction
 
 
 
 --
  This SF.Net email is sponsored by the Verizon Developer Community
  Take advantage of Verizon's best-in-class app development support
  A streamlined, 14 day to market process makes app distribution fast and
 easy
  Join now and get one step closer to millions of Verizon customers
  http://p.sf.net/sfu/verizon-dev2dev
  ___
  Flightgear-devel mailing list
  Flightgear-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/flightgear-devel


 --
 The Planet: dedicated and managed hosting, cloud storage, colocation
 Stay online with enterprise data centers and the best network in the
 business
 Choose flexible plans and management services without long-term contracts
 Personal 24x7 support from experience hosting pros just a phone call away.
 http://p.sf.net/sfu/theplanet-com
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel




-- 
Curtis Olson: http://baron.flightgear.org/~curt/
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] configuration snafu

[John Denker]

On 02/05/2010 02:38 PM, Curtis Olson wrote:
 I don't doubt that there could be some lib vs. lib64 inconsistencies, but
 FilghtGear builds right out of the box for me on 64bit Fedora 12 ... no
 hitches at all that I recall and it has done so for quite some time.

Chez moi plib and simgear install into lib/
while osg installs into lib64/

How do you get around that?  How do recommend I get
around that?

Obviously there are ways, but the only ways I know are 
complicated and devious ... not exactly out-of-the-box.

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] configuration snafu

[Curtis Olson]

On Fri, Feb 5, 2010 at 4:05 PM, John Denker wrote:

 Chez moi plib and simgear install into lib/
 while osg installs into lib64/

 How do you get around that?  How do recommend I get
 around that?

 Obviously there are ways, but the only ways I know are
 complicated and devious ... not exactly out-of-the-box.


Well, I'm not sure I'm doing anything special.  It has just worked for me so
I have never dug in and tried to think about /lib vs. /lib64 with respect to
FlightGear and it's dependencies.  I've heard of others who have built just
fine on 64bit machines, and 64 bit has been out in the wild for a few years
now.

Do you have details of the configure or make error you are seeing posted
somewhere?

My grandmother always said I had more luck than sense ...

Curt.
-- 
Curtis Olson: http://baron.flightgear.org/~curt/
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] configuration snafu

[Martin Spott]

John Denker wrote:

 Chez moi plib and simgear install into lib/
 while osg installs into lib64/
 
 How do you get around that?

Either install OSG from your favourite distribution or build with

  -D LIB_POSTFIX=

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

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] configuration snafu

[John Denker]

On 02/05/2010 03:17 PM, Curtis Olson wrote:

 Do you have details of the configure or make error you are seeing posted
 somewhere?

Yes.  Please take a look at
  http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit

As it says there:

make[1]: Entering directory `/mnt/games/orig/fgs/tests'
g++ -DHAVE_CONFIG_H -I. -I../src/Include   -I/games/orig/usr/include 
-I/usr/local/include  -g -O2 -I/games/orig/usr -D_REENTRANT -MT est-epsilon.o 
-MD -MP -MF .deps/est-epsilon.Tpo -c -o est-epsilon.o est-epsilon.cxx
mv -f .deps/est-epsilon.Tpo .deps/est-epsilon.Po
g++  -g -O2 -I/games/orig/usr -D_REENTRANT  -L/games/orig/usr/lib 
-L/usr/X11R6/lib -L/usr/local/lib -o est-epsilon est-epsilon.o -lglut -lGLU 
-lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm  -losgFX -lglut 
-lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm 
/usr/bin/ld: cannot find -losgFX
collect2: ld returned 1 exit status

The problem is not confined to the tests/ directory. 
If I let the make continue, there will be numerous errors. 
Basically every ld step fails.

Additional root-cause analysis can be found on the 
aforementioned web page.

If you need more details than that, please let me know.

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] configuration snafu

[Curtis Olson]

How about

./configure --prefix=$parent

Curt.


On Fri, Feb 5, 2010 at 4:46 PM, John Denker j...@av8n.com wrote:

 On 02/05/2010 03:17 PM, Curtis Olson wrote:

  Do you have details of the configure or make error you are seeing posted
  somewhere?

 Yes.  Please take a look at
   http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit

 As it says there:

 make[1]: Entering directory `/mnt/games/orig/fgs/tests'
 g++ -DHAVE_CONFIG_H -I. -I../src/Include   -I/games/orig/usr/include
 -I/usr/local/include  -g -O2 -I/games/orig/usr -D_REENTRANT -MT
 est-epsilon.o -MD -MP -MF .deps/est-epsilon.Tpo -c -o est-epsilon.o
 est-epsilon.cxx
 mv -f .deps/est-epsilon.Tpo .deps/est-epsilon.Po
 g++  -g -O2 -I/games/orig/usr -D_REENTRANT  -L/games/orig/usr/lib
 -L/usr/X11R6/lib -L/usr/local/lib -o est-epsilon est-epsilon.o -lglut -lGLU
 -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm  -losgFX -lglut
 -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm
 /usr/bin/ld: cannot find -losgFX
 collect2: ld returned 1 exit status

 The problem is not confined to the tests/ directory.
 If I let the make continue, there will be numerous errors.
 Basically every ld step fails.

 Additional root-cause analysis can be found on the
 aforementioned web page.

 If you need more details than that, please let me know.


 --
 The Planet: dedicated and managed hosting, cloud storage, colocation
 Stay online with enterprise data centers and the best network in the
 business
 Choose flexible plans and management services without long-term contracts
 Personal 24x7 support from experience hosting pros just a phone call away.
 http://p.sf.net/sfu/theplanet-com
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel




-- 
Curtis Olson: http://baron.flightgear.org/~curt/
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] configuration snafu

[Curtis Olson]

And for whatever it's worth, I've been using the default paths for
installing osg (i.e. not specifying any other prefix, I don't know if that
is a key difference in our setups.)

Curt.

On Fri, Feb 5, 2010 at 5:22 PM, Curtis Olson wrote:

 How about

 ./configure --prefix=$parent

 Curt.


 On Fri, Feb 5, 2010 at 4:46 PM, John Denker  wrote:

 On 02/05/2010 03:17 PM, Curtis Olson wrote:

  Do you have details of the configure or make error you are seeing posted
  somewhere?

 Yes.  Please take a look at
   http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit

 As it says there:

 make[1]: Entering directory `/mnt/games/orig/fgs/tests'
 g++ -DHAVE_CONFIG_H -I. -I../src/Include   -I/games/orig/usr/include
 -I/usr/local/include  -g -O2 -I/games/orig/usr -D_REENTRANT -MT
 est-epsilon.o -MD -MP -MF .deps/est-epsilon.Tpo -c -o est-epsilon.o
 est-epsilon.cxx
 mv -f .deps/est-epsilon.Tpo .deps/est-epsilon.Po
 g++  -g -O2 -I/games/orig/usr -D_REENTRANT  -L/games/orig/usr/lib
 -L/usr/X11R6/lib -L/usr/local/lib -o est-epsilon est-epsilon.o -lglut -lGLU
 -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm  -losgFX -lglut
 -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm
 /usr/bin/ld: cannot find -losgFX
 collect2: ld returned 1 exit status

 The problem is not confined to the tests/ directory.
 If I let the make continue, there will be numerous errors.
 Basically every ld step fails.

 Additional root-cause analysis can be found on the
 aforementioned web page.

 If you need more details than that, please let me know.


 --
 The Planet: dedicated and managed hosting, cloud storage, colocation
 Stay online with enterprise data centers and the best network in the
 business
 Choose flexible plans and management services without long-term contracts
 Personal 24x7 support from experience hosting pros just a phone call away.
 http://p.sf.net/sfu/theplanet-com
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel




 --
 Curtis Olson: http://baron.flightgear.org/~curt/




-- 
Curtis Olson: http://baron.flightgear.org/~curt/
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] configuration snafu

[Dale J. Chatham]

I'm assuming a UNIX/Linux system.

Does configure run clean? Look for libraries that it cannot find.

If that's the problem, and if you're on a linux system, you'll need to 
tell configure where to find the libraries.

I usually run:

./configure --help  do.it

Add comments before every line, then at the top put

./configure

along with whatever flags configure needs.

Hope that's helpful.

ln is the linker and it is looking for the entry points to a library for 
a function used in the code.

Curtis Olson wrote:
 How about

 ./configure --prefix=$parent

 Curt.


 On Fri, Feb 5, 2010 at 4:46 PM, John Denker j...@av8n.com 
 mailto:j...@av8n.com wrote:

 On 02/05/2010 03:17 PM, Curtis Olson wrote:

  Do you have details of the configure or make error you are
 seeing posted
  somewhere?

 Yes. Please take a look at
 http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit

 As it says there:

 make[1]: Entering directory `/mnt/games/orig/fgs/tests'
 g++ -DHAVE_CONFIG_H -I. -I../src/Include -I/games/orig/usr/include
 -I/usr/local/include -g -O2 -I/games/orig/usr -D_REENTRANT -MT
 est-epsilon.o -MD -MP -MF .deps/est-epsilon.Tpo -c -o
 est-epsilon.o est-epsilon.cxx
 mv -f .deps/est-epsilon.Tpo .deps/est-epsilon.Po
 g++ -g -O2 -I/games/orig/usr -D_REENTRANT -L/games/orig/usr/lib
 -L/usr/X11R6/lib -L/usr/local/lib -o est-epsilon est-epsilon.o
 -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt
 -ldl -lm -losgFX -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi
 -lXext -lX11 -lrt -ldl -lm
 /usr/bin/ld: cannot find -losgFX
 collect2: ld returned 1 exit status

 The problem is not confined to the tests/ directory.
 If I let the make continue, there will be numerous errors.
 Basically every ld step fails.

 Additional root-cause analysis can be found on the
 aforementioned web page.

 If you need more details than that, please let me know.

 
 --
 The Planet: dedicated and managed hosting, cloud storage, colocation
 Stay online with enterprise data centers and the best network in
 the business
 Choose flexible plans and management services without long-term
 contracts
 Personal 24x7 support from experience hosting pros just a phone
 call away.
 http://p.sf.net/sfu/theplanet-com
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 mailto:Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel




 -- 
 Curtis Olson: http://baron.flightgear.org/~curt/ 
 http://baron.flightgear.org/%7Ecurt/
 

 --
 The Planet: dedicated and managed hosting, cloud storage, colocation
 Stay online with enterprise data centers and the best network in the business
 Choose flexible plans and management services without long-term contracts
 Personal 24x7 support from experience hosting pros just a phone call away.
 http://p.sf.net/sfu/theplanet-com
 

 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   


-- 
“I am for doing good to the poor, but I differ in opinion of the means. I think 
the best way of doing good to the poor, is not making them easy in poverty, but 
leading or driving them out of it. In my youth I travelled much, and I observed 
in different countries, that the more public provisions were made for the poor, 
the less they provided for themselves, and of course became poorer. And, on the 
contrary, the less was done for them, the more they did for themselves, and 
became richer.”

– Ben Franklin


--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] configuration snafu

[Johnathan Van Why]

Curtis Olson wrote:
 It has just worked for me so I have never dug in and tried to think about
/lib vs. /lib64 with respect to FlightGear and it's dependencies.

I'd like to add that Brisa's script (an automated compilation script for
PLIB, OSG, SG, FG, FGCOM, and FGRun) makes a simlink, OpenSceneGraph/lib
that points to OpenSceneGraph/lib64 on 64-bit machines. This works for me
out of the box.

I hope this helps.
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] configurator plebis

[John Denker]

Let summarize a few obvious points:

1) Everybody who is participating in this conversation
is doing so in order to help ordinary non-expert users.
None of use will directly benefit from any cleanup
in the autoconfiguration scripts.

Everybody on this list is an expert.  We all figured 
out years ago how to configure, compile, and link FG.
We do not need to explain to each other how to do it.

As a related point, the whole effort toward making 
a new release depends on people who want to help
ordinary non-expert users.  Almost everybody on this 
list could happily use the development version forever.

2) Consider the following use-case scenario.  Think
about it from the viewpoint of Joe Schmoe, somebody 
who does not have as much skill or as much luck as 
the people on this list.
 -- Joe has a fairly standard 64-bit Linux box.
 -- Joe configures, compiles, and installs OSG from
  source, straight out of the box according to the 
  directions.  So far so good.
 -- Joe configures, compiles, and installs plib 
  straight out of the box according to the directions.  
  So far so good.
 -- Joe configures simgear straight out of the box
  according to the instructions.  The ./configure
  script says the configuration is correct.  However 
  the configuration is not correct.  The makefiles 
  generated by ./configure produce link errors.

This is a bug.  This is so obviously a bug that I am
embarrassed to discuss it.

Yes, you can get FG to compile out of the box if 
you compile OSG using a completely undocumented
non-obvious option.  This is entirely true but it 
entirely misses the point.  On the other side of the
same coin, you can configure OSG out of the box 
if you are willing to configure FG with completely 
undocumented non-obvious options.  This, too, is
entirely true but entirely misses the point.

Instead the point should be that Joe Schmoe is going 
to have a bad experience.  When the simgear make 
fails at a late step, Joe is going to have little 
idea what went wrong, and less idea how to fix it.  
The fact that *I* know how to fix it is not the 
point.  The fact that ten other people on this list 
know how to fix it is not the point.

The ./configure script is supposed to check that all
the right libraries are found.  If they are not found
it is supposed to print an informative, user-friendly
message.  If they are found, it is supposed to remember
where they were found and then build a makefile that
knows about them.  The current ./configure script
does not meet specifications.  This is a bug.  It is 
not a problem for me, but it is a problem for Joe.

3) See item 1.  The only reason we are having this
conversation is because we want to be unselfish.  We
want to make things better for Joe.

4) There's a lot more I could say about this, but I'll
stop here for now.  If anybody has further questions, 
please ask.

===

If you are wondering about the Subject line:
  http://en.wikipedia.org/wiki/Tribunus_plebis

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [patch] 787-set.xml

[YOSHIMATSU Toshihide]

Hi Curt,

Thanks for your reply.

Certainly, at the release timing of v1.9.0, 787_02_2008.zip was built
and have been distributed via ftp.
But it was not included to the aircraft download page, because
your make-aircraft-html.pl can't handle aircraft version which
includes _ (underbar).

Log of make-aircraft-html.pl (generated in Mar. 2009):
 Extracting info from 787_02_2008.zip
 dir = 787_02 version = 2008
 unzip /home/toshi/fg-cvs/install/fgfs/ftp/Aircraft/787_02_2008.zip 
 '787_02/*-set.xml' '787_02/thumbnail.jpg'
 Archive:  /home/toshi/fg-cvs/install/fgfs/ftp/Aircraft/787_02_2008.zip
 caution: filename not matched:  787_02/*-set.xml
 caution: filename not matched:  787_02/thumbnail.jpg
 dir = 787_02 version = 2008
 ls: cannot access /tmp/787_02/*-set.xml: No such file or directory
 dir = 787_02 version = 2008

And because 787 files in current CVS have been changed since v1.9.0, I
think file name of 787_02_2008.zip also should become different name
for next v2.0.0 release.

c.f.
Re: 787 disapeared
http://www.flightgear.org/forums/viewtopic.php?f=2t=3242#p29432

Cheers,
Toshi

From: Curtis Olson curtol...@gmail.com
Subject: Re: [Flightgear-devel] [patch] 787-set.xml
Date: Fri, 5 Feb 2010 15:49:06 -0600

 Hi Toshi,
 
 I think my script will build the 787 just fine (or am I missing something?)
  I believe the reason it wasn't included automatically in the past was
 because it didn't exist is CVS.
 
 Best regards,
 
 Curt.
 
 
 On Fri, Feb 5, 2010 at 11:49 AM, YOSHIMATSU Toshihide wrote:
 
 Hi Curt,

 I quickly saw forum posts about some new 787 aircrafts:
 http://www.flightgear.org/forums/viewtopic.php?f=4t=5207.

 But I couldn't realize which files should be (or planed to be)
 committed to CVS.

 So, would you please simply delete the following line in
 data/Aircraft/787/787-set.xml in cvs?

 aircraft-version02_2008/aircraft-version

 Otherwise, your admin/make-aircraft-html.pl will not include 787 in
 downloads/aircraft/index.shtml.


 Cheers,
 Toshi

 From: YOSHIMATSU Toshihide qzt04...@nifty.ne.jp
 Subject: [Flightgear-devel] [patch] 787-set.xml
 Date: Wed, 06 Jan 2010 00:18:03 +0900 (JST)

  Hi all,
 
  As you may know, 787 aircraft has been disappeared from official
  aircraft download page.
 
  cf.
 
 http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21552.html
 
  To include the 787 on download page at the next release timing, I'll
  send a simple patch for 787-set.xml.
 
  This patch will also have an effect to prevent to become the same file
  name of 787_02_2008.zip with different contents, which were
  committed to cvs after Dec. 2008.
 
 
  Cheers,
  Toshi
 
 
  Index: 787-set.xml
  ===
  RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/787/787-set.xml,v
  retrieving revision 1.9
  diff -u -r1.9 787-set.xml
  --- 787-set.xml   19 Dec 2008 15:23:39 -  1.9
  +++ 787-set.xml   5 Jan 2010 14:45:57 -
  @@ -3,7 +3,6 @@
   descriptionBoeing 787-8/description
   authorJoshua Wilson/author
   statusDevelopment/status
  -aircraft-version02_2008/aircraft-version
   flight-modelyasim/flight-model
   aero787/aero
   fuel-fraction0.10/fuel-fraction
 
 
 
 --
  This SF.Net email is sponsored by the Verizon Developer Community
  Take advantage of Verizon's best-in-class app development support
  A streamlined, 14 day to market process makes app distribution fast and
 easy
  Join now and get one step closer to millions of Verizon customers
  http://p.sf.net/sfu/verizon-dev2dev
  ___
  Flightgear-devel mailing list
  Flightgear-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/flightgear-devel


 --
 The Planet: dedicated and managed hosting, cloud storage, colocation
 Stay online with enterprise data centers and the best network in the
 business
 Choose flexible plans and management services without long-term contracts
 Personal 24x7 support from experience hosting pros just a phone call away.
 http://p.sf.net/sfu/theplanet-com
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel

 
 
 
 -- 
 Curtis Olson: http://baron.flightgear.org/~curt/

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net

Re: [Flightgear-devel] configurator plebis

[Curtis Olson]

This simply isn't the case as I have observed it.  Everything compiles out
of the box here.  I have access to two 64 bit Linux machines.  I run Fedora
if that makes a difference.  OSG, FlightGear, Simgear, plib go together
without expert magic using the default configure paths.  We could work to
try to figure out what the difference is between your experience and others
who have also been successful with 64 bit machines.  There's probably a
difference in methodology, or paths or something.  Or we could stand on our
soapboxes and make grand proclamations.  I was hoping we were doing the
former.  I did share my configure options.  Please understand I'm not
trying to claim you are doing something stupid which it appears is how you
interpreted my message.  I was hoping to drill down to what we were doing
that was different.  I'd prefer to make configure script changes with a full
understanding of the issues rather than hacking and slashing everything up
... especially in consideration that the current configure scripts do work
on 64bit machines for a lot of people.

Regards,

Curt.


On Fri, Feb 5, 2010 at 7:29 PM, John Denker wrote:

 Let summarize a few obvious points:

 1) Everybody who is participating in this conversation
 is doing so in order to help ordinary non-expert users.
 None of use will directly benefit from any cleanup
 in the autoconfiguration scripts.

 Everybody on this list is an expert.  We all figured
 out years ago how to configure, compile, and link FG.
 We do not need to explain to each other how to do it.

 As a related point, the whole effort toward making
 a new release depends on people who want to help
 ordinary non-expert users.  Almost everybody on this
 list could happily use the development version forever.

 2) Consider the following use-case scenario.  Think
 about it from the viewpoint of Joe Schmoe, somebody
 who does not have as much skill or as much luck as
 the people on this list.
  -- Joe has a fairly standard 64-bit Linux box.
  -- Joe configures, compiles, and installs OSG from
  source, straight out of the box according to the
  directions.  So far so good.
  -- Joe configures, compiles, and installs plib
  straight out of the box according to the directions.
  So far so good.
  -- Joe configures simgear straight out of the box
  according to the instructions.  The ./configure
  script says the configuration is correct.  However
  the configuration is not correct.  The makefiles
  generated by ./configure produce link errors.

 This is a bug.  This is so obviously a bug that I am
 embarrassed to discuss it.

 Yes, you can get FG to compile out of the box if
 you compile OSG using a completely undocumented
 non-obvious option.  This is entirely true but it
 entirely misses the point.  On the other side of the
 same coin, you can configure OSG out of the box
 if you are willing to configure FG with completely
 undocumented non-obvious options.  This, too, is
 entirely true but entirely misses the point.

 Instead the point should be that Joe Schmoe is going
 to have a bad experience.  When the simgear make
 fails at a late step, Joe is going to have little
 idea what went wrong, and less idea how to fix it.
 The fact that *I* know how to fix it is not the
 point.  The fact that ten other people on this list
 know how to fix it is not the point.

 The ./configure script is supposed to check that all
 the right libraries are found.  If they are not found
 it is supposed to print an informative, user-friendly
 message.  If they are found, it is supposed to remember
 where they were found and then build a makefile that
 knows about them.  The current ./configure script
 does not meet specifications.  This is a bug.  It is
 not a problem for me, but it is a problem for Joe.

 3) See item 1.  The only reason we are having this
 conversation is because we want to be unselfish.  We
 want to make things better for Joe.

 4) There's a lot more I could say about this, but I'll
 stop here for now.  If anybody has further questions,
 please ask.

 ===

 If you are wondering about the Subject line:
  http://en.wikipedia.org/wiki/Tribunus_plebis


 --
 The Planet: dedicated and managed hosting, cloud storage, colocation
 Stay online with enterprise data centers and the best network in the
 business
 Choose flexible plans and management services without long-term contracts
 Personal 24x7 support from experience hosting pros just a phone call away.
 http://p.sf.net/sfu/theplanet-com
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel




-- 
Curtis Olson: http://baron.flightgear.org/~curt/
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers 

Re: [Flightgear-devel] configurator plebis

[John Denker]

On 02/05/2010 06:43 PM, Curtis Olson wrote:
 This simply isn't the case as I have observed it.  Everything compiles out
 of the box here.  I have access to two 64 bit Linux machines.  I run Fedora
 if that makes a difference.  OSG, FlightGear, Simgear, plib go together
 without expert magic using the default configure paths.  We could work to
 try to figure out what the difference is between your experience and others
 who have also been successful with 64 bit machines.  There's probably a
 difference in methodology, or paths or something.  Or we could stand on our
 soapboxes and make grand proclamations.  I was hoping we were doing the
 former.  I did share my configure options.  

And I have shared mine.

 Please understand I'm not
 trying to claim you are doing something stupid which it appears is how you
 interpreted my message.  I was hoping to drill down to what we were doing
 that was different.  I'd prefer to make configure script changes with a full
 understanding of the issues rather than hacking and slashing everything up
 ... especially in consideration that the current configure scripts do work
 on 64bit machines for a lot of people.

Did you try downloading the OSG 2.8.2 source from
  http://www.openscenegraph.org/projects/osg/wiki/Downloads
and compiling it, as mentioned in the use-case example 
I posted?

All evidence suggests that this is the sticking point.

AFAICT all the major distributions install OSG in .../lib/.
That presumably applies to source RPMs as well as binaries.  
In contrast, downloading it from openscengraph.org and 
compiling it, without any undocumented expert incantations, 
installs it in .../lib64/ -- unless they have changed
something very recently without telling anybody.

If you're going to do the experiment, you need to 
temporarily de-install the distro's version, or 
otherwise take pains to make sure it doesn't muddy
the waters.

If this is not sufficient understanding, please re-ask 
the question.



The note from Martin Spott on 02/05/2010 03:33 PM indicates
that he understands the issues.

   -D LIB_POSTFIX=

Actually I suspect that should have said

  -DLIB_POSTFIX:STRING=

since OSG is using cmake these days.  

Another workaround -- the one I actually prefer -- is to
let OSG live under .../lib64/ but add

   LDFLAGS=$LDFLAGS -L$parent/usr/lib64  \
   LDFLAGS=$LDFLAGS -L$parent/usr/lib  \
   ./configure

to the SG and FG ./configure invocations.

Both of these workarounds fall into the category of 
undocumented expert incantations.  Neither is a good
substitute for actually fixing the autoconf setup.

=

Please consider this line of argument:  

Whenever the OSG libraries are truly missing or truly
misplaced, the FG ./configure script behaves as it should.
It prints a user-friendly error message

  You *must* have the OpenSceneGraph support library installed on your system
  to build this version of SimGear!

and then exists without writing any makefiles.

It is interesting that when OSG is installed under lib64/,
./configure can find the libraries long enough to decide 
*not* to throw any errors.  I take this as quite strong
evidence that the OSG libraries are not missing and are
not misplaced.  Alas, ./configure blissfully proceeds to
write makefiles that cannot find those libraries.

This is a bug.  The bug is not hard to reproduce.  The
bug is almost certainly a problem for anybody who compiles 
OSG from source downloaded from the OSG site.


--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Feedback ReleaseCandidate4

[James Turner]

On 5 Feb 2010, at 21:14, syd adams adams@gmail.com wrote:



-VNAV only follows airports- but not any other Waypoints like VOR,  
NDB,

fixes
Only when frq turned to VOR

VNAV shouldn't follow ANY waypoint ... so I'm assuming you mean LNAV .
If I understand Jame's gps changes ... I should be able to eliminate  
my nasal routines that detect the difference and simply use the  
autopilot nav1 offsets for FMS and vor modes.


Almost - for an FMS equipped aircraft, my intention is that people  
leave nav1 as a pure VOR receiver (ie gps-slaved property is always  
false), and instead read the 'FMS course' from the gps properties  
directly. This should simplify many things for your cockpit displays,  
especially the VOR needle overlays in MAP mode on the ND.


Regards,
James



-TO/GA-mode let the aircraft circle

Doc about the real thing: 
http://www.smartcockpit.com/pdf/plane/boeing/B777/systems/0004/

Ive had those docs for quite a while --- its just a matter of  
getting the chance to read them through.
I haven't been able to grow another pair of arms yet , so bear with  
me :)


Cheers
HHS
--- 
--- 
--- 
-

The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the  
business
Choose flexible plans and management services without long-term  
contracts
Personal 24x7 support from experience hosting pros just a phone call  
away.

http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel