Re: [Flightgear-devel] mouse acceleration

2011-01-08 Thread syd adams
I knew this was too easy , and looking for the reason , but the
acceleration properties don't zero out when the mouse stops moving .
While it still works to a point , still not quite right.

--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] mouse acceleration

2011-01-08 Thread Torsten Dreyer
 could you invert the y
 acceleration before updating the property ?
 
Sorry, my bad. It's inverted now.

Torsten

--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] mouse acceleration

2011-01-08 Thread syd adams
After a quick investigation , i see that the acceleration properties
are only updated IF there has been a mouse movement , so they retain
the last value ... my oversight.
Should I make a patch , or leave this to you Torsten ?
Cheers

On Sat, Jan 8, 2011 at 1:03 AM, syd adams adams@gmail.com wrote:
 I knew this was too easy , and looking for the reason , but the
 acceleration properties don't zero out when the mouse stops moving .
 While it still works to a point , still not quite right.


--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] new install git hung up // xplane airport format

2011-01-08 Thread Michael Sgier
Hi after several months i try to install the latest 
with:http://wiki.flightgear.org/index.php/Scripted_Compilation_on_Linux_Debian/Ubuntuand
 get:
Initialized empty Git repository in /media/sda6/fgfs/install/fgfs/fgdata/.git/
remote: Counting objects: 151389, done.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
mich...@ubuntu:/media/sda6/fgfs$

same yesterday...wait longer?
Did some work happen on integration of x-plane 8.6/9 airport layouts? (apt.dat)
Regards Michael




  --
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] mouse acceleration

2011-01-08 Thread syd adams
No problem , and thanks . Imagine where flightgear would be now if
everything worked the way it was meant too on the first try :)

On Sat, Jan 8, 2011 at 1:13 AM, Torsten Dreyer tors...@t3r.de wrote:
 could you invert the y
 acceleration before updating the property ?

 Sorry, my bad. It's inverted now.

 Torsten

 --
 Gaining the trust of online customers is vital for the success of any company
 that requires sensitive data to be transmitted over the Web.   Learn how to
 best implement a security strategy that keeps consumers' information secure
 and instills the confidence they need to proceed with transactions.
 http://p.sf.net/sfu/oracle-sfdevnl
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel


--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] mouse acceleration

2011-01-08 Thread Torsten Dreyer
 I knew this was too easy , and looking for the reason , but the
 acceleration properties don't zero out when the mouse stops moving .
 While it still works to a point , still not quite right.
Hmm - I have no idea how to solve that. Our mouse motion handler gets called 
with last movement since last call, so we might not received a mouse has 
stopped call :-(

Torsten

--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] mouse acceleration

2011-01-08 Thread syd adams
Ive tried a few solutions to zero the properties , but then the
animation stops working .With the current implementation , the mouse
can leave the picked object while the button is pressed and continue
to move the lever , so for the moment this
seems to work ...



On Sat, Jan 8, 2011 at 1:27 AM, Torsten Dreyer tors...@t3r.de wrote:
 I knew this was too easy , and looking for the reason , but the
 acceleration properties don't zero out when the mouse stops moving .
 While it still works to a point , still not quite right.
 Hmm - I have no idea how to solve that. Our mouse motion handler gets called
 with last movement since last call, so we might not received a mouse has
 stopped call :-(

 Torsten

 --
 Gaining the trust of online customers is vital for the success of any company
 that requires sensitive data to be transmitted over the Web.   Learn how to
 best implement a security strategy that keeps consumers' information secure
 and instills the confidence they need to proceed with transactions.
 http://p.sf.net/sfu/oracle-sfdevnl
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel


--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Latest git results in massive NAN errors with Tu154B

2011-01-08 Thread Curtis Olson
Hi Jacob,

The tu154 appears to be working fine for me here with the latest git as of
Saturday morning.  You might try doing a make clean and rebuild for
simgear/flightgear just to rule out that there isn't any weirdness that has
crept into your local tree, or maybe something got out of sync between
system updates and flightgear/simgear code updates.

Regards,

Curt.



On Thu, Jan 6, 2011 at 2:21 PM, Jacob Burbach wrote:

 Updated my copy yesterday and now I cannot load flightgear with the
 Tu154B anymore. Trying just results in massive amounts of NAN errors
 and crash. Looks like the entire property tree and everything else got
 NaNifiedsee log.

 Anyone have any clues what may have changed to cause this? Aircraft
 hasn't changed in months and has always worked perfectly with git
 until this fresh build yesterday.

 log is here http://pastebin.com/utrUVmeu (would attach but got
 rejected by list mod)

 cheers


 --
 Learn how Oracle Real Application Clusters (RAC) One Node allows customers
 to consolidate database storage, standardize their database environment,
 and,
 should the need arise, upgrade to a full multi-node Oracle RAC database
 without downtime or disruption
 http://p.sf.net/sfu/oracle-sfdevnl
 ___
 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://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/
--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] new install git hung up // xplane airport format

2011-01-08 Thread Csaba Halász
On Sat, Jan 8, 2011 at 9:19 AM, Michael Sgier scrat_h...@yahoo.com wrote:

 Initialized empty Git repository in /media/sda6/fgfs/install/fgfs/fgdata/.git/
 remote: Counting objects: 151389, done.
 fatal: The remote end hung up unexpectedly
 fatal: early EOF
 fatal: index-pack failed
 mich...@ubuntu:/media/sda6/fgfs$

 same yesterday...wait longer?

gitorious is known to have problem with fgdata. Use the mapserver
mirror or the fgdata bundle as described at
http://wiki.flightgear.org/index.php/Building_FlightGear_-_Debian#FlightGear_data

-- 
Cheers,
Csaba/Jester

--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Datapath name

2011-01-08 Thread Curtis Olson
I'm not seeing where PACKAGE is explicitly set anywhere in configure.ac or
Makefile.am

This might not be a change we made, but perhaps a change in the underlying
autotools software defaults?

In configure.ac we have:

AC_INIT(FlightGear, m4_esyscmd([cat ./version | tr -d '\n']), [
http://www.flightgear.org])

I *think* that this is where @PACKAGE@ get's defined for the autoconf
system, and as you can see, it's still properly capitalized in our
configuration.  Perhaps the autotools are forcing everything to lower case?

If you add --fg-root= into your ~/.fgfsrc then it shouldn't matter ...

Regards,

Curt.


On Tue, Jan 4, 2011 at 5:42 PM, Ron Jensen wrote:

 I haven't pulled from git for a while.  I built last night and discovered
 the
 name of the data paths has changed from FlightGear to flightgear.  I assume
 this is unintentional?  Would someone give me a hint on how to change this
 back?

 Thanks
 Ron

 (old source Makefile)
 pkgdatadir = $(datadir)/FlightGear
 pkglibdir = $(libdir)/FlightGear
 pkgincludedir = $(includedir)/FlightGear

 (new source Makefile)
 pkgdatadir = $(datadir)/flightgear
 pkglibdir = $(libdir)/flightgear
 pkgincludedir = $(includedir)/flightgear




 --
 Learn how Oracle Real Application Clusters (RAC) One Node allows customers
 to consolidate database storage, standardize their database environment,
 and,
 should the need arise, upgrade to a full multi-node Oracle RAC database
 without downtime or disruption
 http://p.sf.net/sfu/oracle-sfdevnl
 ___
 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://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/
--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Latest git results in massive NAN errors with Tu154B

2011-01-08 Thread Jacob Burbach
On Sat, Jan 8, 2011 at 9:59 AM, Curtis Olson curtol...@gmail.com wrote:
 Hi Jacob,
 The tu154 appears to be working fine for me here with the latest git as of
 Saturday morning.  You might try doing a make clean and rebuild for
 simgear/flightgear just to rule out that there isn't any weirdness that has
 crept into your local tree, or maybe something got out of sync between
 system updates and flightgear/simgear code updates.
 Regards,
 Curt.

Hmm, I'll try again to be sure, but I always do a make clean  make
install whenever dealing with simgear/flightgear because of issues in
past. Also just to be clear I am referring to the Tu154B from Yurik,
not the old Tu154 in the flightgear repository.

http://yurik.flightgear.ru/tu154b-release/tu154b-1.0_jun2010.tar.gz
svn://hlserver.lin.irk.ru/trunk/TU154B

cheers

--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Latest git results in massive NAN errors with Tu154B

2011-01-08 Thread Curtis Olson
On Sat, Jan 8, 2011 at 11:20 AM, Jacob Burbach wrote:

 Hmm, I'll try again to be sure, but I always do a make clean  make
 install whenever dealing with simgear/flightgear because of issues in
 past. Also just to be clear I am referring to the Tu154B from Yurik,
 not the old Tu154 in the flightgear repository.

 http://yurik.flightgear.ru/tu154b-release/tu154b-1.0_jun2010.tar.gz
 svn://hlserver.lin.irk.ru/trunk/TU154B


Oh, then I don't know ... I've always lived in the world of our git aircraft
and haven't gone out and tried any of the 3rd party aircraft.  (And sorry to
waste a message saying I don't know ...)

Regards,

Curt.
-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org -
http://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/
--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Latest git results in massive NAN errors with Tu154B

2011-01-08 Thread Jacob Burbach
On Sat, Jan 8, 2011 at 12:24 PM, Curtis Olson curtol...@gmail.com wrote:
 Oh, then I don't know ... I've always lived in the world of our git aircraft
 and haven't gone out and tried any of the 3rd party aircraft.  (And sorry to
 waste a message saying I don't know ...)
 Regards,
 Curt.
Too bad, if that's true your missing out on a few of the best aircraft
flightgear has to offer. ;-)

Well, I know others fly it, and links are there for anyone else who
wants to take ten minutes to test it out. Personally I'd be concerned
about the possibility that something has changed that could trigger
such a massive nan breakage with a release nearing, regardless of the
aircraft origin...but to each his own.

cheers

--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] Latest GIT crashes after ~30 min. playtime

2011-01-08 Thread Roland Haeder
Hello all,

I have a segfault after about 30-40 minutes flight time with both
optimized and debug build. I flew the A380 the attached flight plan with
maximum altitude of 15.000ft (not much) from EDDH to LHBP.

I also included a full backtrace, so please take a look. :)

Regards,
Roland

PS: If the attachments are not comming through I can upload it to my
FlightGear subdomain (and no, I won't register with Google Code).


EDDH-LHBP-13R
Description: XML document
#0  osgParticle::ParticleSystemUpdater::traverse (this=0x1215ba0, nv=...)
at /home/quix0r/fgfs/osg/src/osgParticle/ParticleSystemUpdater.cpp:43
ps = 0x0
t = 1255.441212
#1  0x73e95fca in traverse (this=0x148c640, node=...) at /home/quix0r/fgfs/osg/include/osg/NodeVisitor:191
No locals.
#2  handle_cull_callbacks_and_traverse (this=0x148c640, node=...) at /home/quix0r/fgfs/osg/include/osgUtil/CullVisitor:300
callback = value optimized out
#3  osgUtil::CullVisitor::apply (this=0x148c640, node=...) at /home/quix0r/fgfs/osg/src/osgUtil/CullVisitor.cpp:751
node_state = 0x0
#4  0x74e67069 in osgParticle::ParticleSystemUpdater::accept (this=0x1215ba0, nv=...)
at /home/quix0r/fgfs/osg/include/osgParticle/ParticleSystemUpdater:44
No locals.
#5  0x73addb83 in osg::Group::traverse (this=0xca7cf70, nv=...) at /home/quix0r/fgfs/osg/src/osg/Group.cpp:62
No locals.
#6  0x73e96caa in traverse (this=0x148c640, node=...) at /home/quix0r/fgfs/osg/include/osg/NodeVisitor:191
No locals.
#7  handle_cull_callbacks_and_traverse (this=0x148c640, node=...) at /home/quix0r/fgfs/osg/include/osgUtil/CullVisitor:300
callback = value optimized out
#8  osgUtil::CullVisitor::apply (this=0x148c640, node=...) at /home/quix0r/fgfs/osg/src/osgUtil/CullVisitor.cpp:1008
node_state = 0x0
#9  0x750a15b9 in osg::Group::accept (this=0xca7cf70, nv=...) at /home/quix0r/fgfs/osg/include/osg/Group:38
No locals.
#10 0x73addb83 in osg::Group::traverse (this=0xca7c9c0, nv=...) at /home/quix0r/fgfs/osg/src/osg/Group.cpp:62
No locals.
#11 0x73e96caa in traverse (this=0x148c640, node=...) at /home/quix0r/fgfs/osg/include/osg/NodeVisitor:191
No locals.
#12 handle_cull_callbacks_and_traverse (this=0x148c640, node=...) at /home/quix0r/fgfs/osg/include/osgUtil/CullVisitor:300
callback = value optimized out
#13 osgUtil::CullVisitor::apply (this=0x148c640, node=...) at /home/quix0r/fgfs/osg/src/osgUtil/CullVisitor.cpp:1008
node_state = 0xfe1dfd0
#14 0x750a15b9 in osg::Group::accept (this=0xca7c9c0, nv=...) at /home/quix0r/fgfs/osg/include/osg/Group:38
No locals.
#15 0x73addb83 in osg::Group::traverse (this=0xfd5edf0, nv=...) at /home/quix0r/fgfs/osg/src/osg/Group.cpp:62
No locals.
#16 0x73e96caa in traverse (this=0x148c640, node=...) at /home/quix0r/fgfs/osg/include/osg/NodeVisitor:191
No locals.
#17 handle_cull_callbacks_and_traverse (this=0x148c640, node=...) at /home/quix0r/fgfs/osg/include/osgUtil/CullVisitor:300
callback = value optimized out
#18 osgUtil::CullVisitor::apply (this=0x148c640, node=...) at /home/quix0r/fgfs/osg/src/osgUtil/CullVisitor.cpp:1008
node_state = 0xfd7cc50
#19 0x750a15b9 in osg::Group::accept (this=0xfd5edf0, nv=...) at /home/quix0r/fgfs/osg/include/osg/Group:38
No locals.
#20 0x73addb83 in osg::Group::traverse (this=0x122fbe0, nv=...) at /home/quix0r/fgfs/osg/src/osg/Group.cpp:62
No locals.
#21 0x73e96caa in traverse (this=0x148c640, node=...) at /home/quix0r/fgfs/osg/include/osg/NodeVisitor:191
No locals.
#22 handle_cull_callbacks_and_traverse (this=0x148c640, node=...) at /home/quix0r/fgfs/osg/include/osgUtil/CullVisitor:300
callback = value optimized out
#23 osgUtil::CullVisitor::apply (this=0x148c640, node=...) at /home/quix0r/fgfs/osg/src/osgUtil/CullVisitor.cpp:1008
node_state = 0xfd61730
#24 0x750a15b9 in osg::Group::accept (this=0x122fbe0, nv=...) at /home/quix0r/fgfs/osg/include/osg/Group:38
No locals.
#25 0x73b7808b in osg::Switch::traverse (this=0x118eda40, nv=...) at /home/quix0r/fgfs/osg/src/osg/Switch.cpp:40
pos = 0
#26 0x73e96caa in traverse (this=0x148c640, node=...) at /home/quix0r/fgfs/osg/include/osg/NodeVisitor:191
No locals.
#27 handle_cull_callbacks_and_traverse (this=0x148c640, node=...) at /home/quix0r/fgfs/osg/include/osgUtil/CullVisitor:300
callback = value optimized out
#28 osgUtil::CullVisitor::apply (this=0x148c640, node=...) at /home/quix0r/fgfs/osg/src/osgUtil/CullVisitor.cpp:1008
node_state = 0x0
#29 0x73b7a4ec in osg::Switch::accept (this=0x118eda40, nv=...) at /home/quix0r/fgfs/osg/include/osg/Switch:40
No locals.
#30 0x73addb83 in osg::Group::traverse (this=0x1378760, nv=...) at /home/quix0r/fgfs/osg/src/osg/Group.cpp:62
No locals.
#31 0x73e96caa in traverse (this=0x148c640, node=...) at /home/quix0r/fgfs/osg/include/osg/NodeVisitor:191
No locals.
#32 

Re: [Flightgear-devel] Latest git results in massive NAN errors with Tu154B

2011-01-08 Thread Jacob Burbach
No worries Curt, certainly wasn't trying to say you personally have to
look into it or make it a priority or anything..I know your a busy guy
like the rest of us. Was just saying the links are there if anyone
else is interested in giving it a try. I've never seen nan errors like
this before myself, and whatever may have changed I don't think it
could be more than a week or two old as it was working fine with git
builds back then.

cheers!

--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] 2.2.0 Release branches

2011-01-08 Thread James Turner
(playing virtual Durk, since he's in Antarctica for a month)

I'm planning to create releases/2.2.0 branches of both Simgear and FlightGear 
tomorrow, based on current state of 'next' at that time. This is not intended 
to provoke a commit rush - if the code isn't in Gitorious now, it should 
probably wait until the next release (which should be sooner than 12 months 
time - ideally in time for LinuxTag)

If you make *bug-fixes* after the branches are created, please apply them to 
next, and then cherry-pick (or equivalent) them into the release heads.

I'll create -rc1 tags as soon as the branches are cut, to provide a reference 
point - I believe Dave Luff and Tim Moore have some bug-fixes pending, but 
there's plenty of value in wider testing of the current state of the code.

I should point out that the current nightly build infrastructure *does not* 
help with producing release candidates or final builds. I am doing some hacking 
in that direction, but for the moment, Hudson builds next, and *only* next - as 
soon as we branch, the Hudson visibility is gone. Hence, we're completely 
reliant on manual intervention to produce source and binary packages once the 
tags are created. (As we have been for every previous release, of course)

If anyone has issues or objections to this, I assume you'll speak up :)

Regards,
James


--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Latest GIT crashes after ~30 min. playtime

2011-01-08 Thread Olaf Flebbe
Hi,

since it crashes within OSG you should state which OSG version you did use.

Cheers,
   Olaf


 Hello all,

 I have a segfault after about 30-40 minutes flight time with both
 optimized and debug build. I flew the A380 the attached flight plan with
 maximum altitude of 15.000ft (not much) from EDDH to LHBP.

 I also included a full backtrace, so please take a look. :)

 Regards,
 Roland

 PS: If the attachments are not comming through I can upload it to my
 FlightGear subdomain (and no, I won't register with Google Code).



 --
 Gaining the trust of online customers is vital for the success of any company
 that requires sensitive data to be transmitted over the Web.   Learn how to
 best implement a security strategy that keeps consumers' information secure
 and instills the confidence they need to proceed with transactions.
 http://p.sf.net/sfu/oracle-sfdevnl



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


--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Latest GIT crashes after ~30 min. playtime

2011-01-08 Thread Roland Haeder
Hi,

2.8.3 from SVN, own build. My Debian Unstable provides me 2.8.3-6.

Roland

On Sat, 2011-01-08 at 20:01 +0100, Olaf Flebbe wrote:
 Hi,
 
 since it crashes within OSG you should state which OSG version you did use.
 
 Cheers,
Olaf



signature.asc
Description: This is a digitally signed message part
--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] 2.2.0 Release branches

2011-01-08 Thread Roland Haeder
Hi,

I have an FPE to report and a small fix (I already mentioned the FPE in
IRC chat).

The fix is included, with some white-space cleanup.

Regards,
Roland

On Sat, 2011-01-08 at 18:59 +, James Turner wrote:
 (playing virtual Durk, since he's in Antarctica for a month)
 
 I'm planning to create releases/2.2.0 branches of both Simgear and FlightGear 
 tomorrow, based on current state of 'next' at that time. This is not intended 
 to provoke a commit rush - if the code isn't in Gitorious now, it should 
 probably wait until the next release (which should be sooner than 12 months 
 time - ideally in time for LinuxTag)
 
 If you make *bug-fixes* after the branches are created, please apply them to 
 next, and then cherry-pick (or equivalent) them into the release heads.
 
 I'll create -rc1 tags as soon as the branches are cut, to provide a reference 
 point - I believe Dave Luff and Tim Moore have some bug-fixes pending, but 
 there's plenty of value in wider testing of the current state of the code.
 
 I should point out that the current nightly build infrastructure *does not* 
 help with producing release candidates or final builds. I am doing some 
 hacking in that direction, but for the moment, Hudson builds next, and *only* 
 next - as soon as we branch, the Hudson visibility is gone. Hence, we're 
 completely reliant on manual intervention to produce source and binary 
 packages once the tags are created. (As we have been for every previous 
 release, of course)
 
 If anyone has issues or objections to this, I assume you'll speak up :)
 
 Regards,
 James
 
 
 --
 Gaining the trust of online customers is vital for the success of any company
 that requires sensitive data to be transmitted over the Web.   Learn how to 
 best implement a security strategy that keeps consumers' information secure 
 and instills the confidence they need to proceed with transactions.
 http://p.sf.net/sfu/oracle-sfdevnl 
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel

diff --git a/src/AIModel/AIShip.cxx b/src/AIModel/AIShip.cxx
index 9b6a047..4d8279e 100644
--- a/src/AIModel/AIShip.cxx
+++ b/src/AIModel/AIShip.cxx
@@ -624,6 +624,9 @@ void FGAIShip::ProcessFlightPlan(double dt) {
 	return;
 }
 
+// Avoids a FPE
+if (dt = 0.0) return;
+
 double time_sec = getDaySeconds();
 
 _dt_count += dt;
diff --git a/src/Input/FGEventInput.cxx b/src/Input/FGEventInput.cxx
index 29ee097..8bf9f30 100644
--- a/src/Input/FGEventInput.cxx
+++ b/src/Input/FGEventInput.cxx
@@ -24,6 +24,7 @@
 #  include config.h
 #endif
 
+#include cstring
 #include FGEventInput.hxx
 #include Main/fg_props.hxx
 #include simgear/io/sg_file.hxx
diff --git a/src/Input/FGLinuxEventInput.cxx b/src/Input/FGLinuxEventInput.cxx
index 621e15f..c79a642 100644
--- a/src/Input/FGLinuxEventInput.cxx
+++ b/src/Input/FGLinuxEventInput.cxx
@@ -24,6 +24,10 @@
 #  include config.h
 #endif
 
+#include cstring
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
 #include FGLinuxEventInput.hxx
 
 #include poll.h


signature.asc
Description: This is a digitally signed message part
--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] 2.2.0 Release branches

2011-01-08 Thread Roland Haeder
And the patch includes some extra include lines which fixes some
compiler errors.

On Sat, 2011-01-08 at 20:44 +0100, Roland Haeder wrote:
 Hi,
 
 I have an FPE to report and a small fix (I already mentioned the FPE in
 IRC chat).
 
 The fix is included, with some white-space cleanup.
 
 Regards,
 Roland



signature.asc
Description: This is a digitally signed message part
--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Datapath name

2011-01-08 Thread Jari Häkkinen
The problem was introduced in November 2010 in commit 
http://gitorious.org/fg/flightgear/commit/a6458c2ed64757b1f416b0035df142d29359239e

The change of line 17 triggers the change of string 'FlightGear' to 
'flightgear' in the Makefile. However, the change of AM_INIT_AUTOMAKE is 
preferred since the previous usage of the macro in flightgear is 
deprecated. The pre-Npv2010 usage of AM_INIT_AUTOMAKE does not match the 
default automake naming scheme. Remember autotools is created by 
unix-people and they are generally not CamelCase friendly.

The AC_INIT line sets many strings (such as PACKAGE_NAME to FlightGear) 
but not string PACKAGE that is actually set by AM_INIT_AUTOMAKE to 
flightgear. The PACKAGE string is used to derive the tar-ball name.

There is probably ways around it but I suggest that FlightGear data 
directories are renamed to flightgear. Or follow Curt's --fg-root advice

Cheers,

Jari



On 2011-01-08 17.38, Curtis Olson wrote:
 I'm not seeing where PACKAGE is explicitly set anywhere in configure.ac or
 Makefile.am

 This might not be a change we made, but perhaps a change in the underlying
 autotools software defaults?

 In configure.ac we have:

 AC_INIT(FlightGear, m4_esyscmd([cat ./version | tr -d '\n']), [
 http://www.flightgear.org])

 I *think* that this is where @PACKAGE@ get's defined for the autoconf
 system, and as you can see, it's still properly capitalized in our
 configuration.  Perhaps the autotools are forcing everything to lower case?

 If you add --fg-root= into your ~/.fgfsrc then it shouldn't matter ...

 Regards,

 Curt.


 On Tue, Jan 4, 2011 at 5:42 PM, Ron Jensen wrote:

 I haven't pulled from git for a while.  I built last night and discovered
 the
 name of the data paths has changed from FlightGear to flightgear.  I assume
 this is unintentional?  Would someone give me a hint on how to change this
 back?

 Thanks
 Ron

 (old source Makefile)
 pkgdatadir = $(datadir)/FlightGear
 pkglibdir = $(libdir)/FlightGear
 pkgincludedir = $(includedir)/FlightGear

 (new source Makefile)
 pkgdatadir = $(datadir)/flightgear
 pkglibdir = $(libdir)/flightgear
 pkgincludedir = $(includedir)/flightgear




 --
 Learn how Oracle Real Application Clusters (RAC) One Node allows customers
 to consolidate database storage, standardize their database environment,
 and,
 should the need arise, upgrade to a full multi-node Oracle RAC database
 without downtime or disruption
 http://p.sf.net/sfu/oracle-sfdevnl
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel






 --
 Gaining the trust of online customers is vital for the success of any company
 that requires sensitive data to be transmitted over the Web.   Learn how to
 best implement a security strategy that keeps consumers' information secure
 and instills the confidence they need to proceed with transactions.
 http://p.sf.net/sfu/oracle-sfdevnl



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

--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Datapath name

2011-01-08 Thread James Turner

On 8 Jan 2011, at 19:46, Jari Häkkinen wrote:

 The problem was introduced in November 2010 in commit 
 http://gitorious.org/fg/flightgear/commit/a6458c2ed64757b1f416b0035df142d29359239e
 
 The change of line 17 triggers the change of string 'FlightGear' to 
 'flightgear' in the Makefile. However, the change of AM_INIT_AUTOMAKE is 
 preferred since the previous usage of the macro in flightgear is 
 deprecated. The pre-Npv2010 usage of AM_INIT_AUTOMAKE does not match the 
 default automake naming scheme. Remember autotools is created by 
 unix-people and they are generally not CamelCase friendly.
 
 The AC_INIT line sets many strings (such as PACKAGE_NAME to FlightGear) 
 but not string PACKAGE that is actually set by AM_INIT_AUTOMAKE to 
 flightgear. The PACKAGE string is used to derive the tar-ball name.
 
 There is probably ways around it but I suggest that FlightGear data 
 directories are renamed to flightgear. Or follow Curt's --fg-root advice

As Jari notes, this was an unintentional effect of me updating configure.ac to 
use the currently-recommened _INIT_ macros for autoconf and automake. My 
concern was to get the version number encoded in a way that other builds tools 
besides configure could 'see' - hence the ugly 'm4_esyscmd' trick which is 
apparently the standard way of accomplishing this.

Obviously I didn't change the package name when I made the change - it's still 
'FlightGear' - but the autoconf docs do state that the package name (eg, for 
'make dist' tarbballs) is created by changing this to lowercase, and replacing 
all non-alphanumeric characters with an underscore. I presume the autoconf 
maintainers would say this is a feature, but it's subjective :)

Unfortunately I don't have a solution to restore the old naming scheme - 
perhaps we can simply override the value of the autoconf PACKAGE variable after 
invoking AC_INIT? I don't know what other paths and names are derived from this 
value, and if that will trigger other problems. The path of least resistance 
would be to accept autoconf's naming scheme, but maybe that's unpalatable.

Regards,
James


--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Datapath name

2011-01-08 Thread Jari Häkkinen
Adding the next two lines

dnl Next line is to retain backward compatibility for PACKAGE variable
AC_SUBST([PACKAGE],[$PACKAGE_NAME])

after

AM_INIT_AUTOMAKE([dist-bzip2])

will give back FlightGear in Makefile and other places. I cannot safely 
say that there won't be any side effects. It may be a way to retain 
backward compatibility. But it will complicate autotools usage since it 
breaks standard autotools behaviour.


Jari


On 2011-01-08 21.47, James Turner wrote:

 On 8 Jan 2011, at 19:46, Jari Häkkinen wrote:

 The problem was introduced in November 2010 in commit
 http://gitorious.org/fg/flightgear/commit/a6458c2ed64757b1f416b0035df142d29359239e

 The change of line 17 triggers the change of string 'FlightGear' to
 'flightgear' in the Makefile. However, the change of AM_INIT_AUTOMAKE is
 preferred since the previous usage of the macro in flightgear is
 deprecated. The pre-Npv2010 usage of AM_INIT_AUTOMAKE does not match the
 default automake naming scheme. Remember autotools is created by
 unix-people and they are generally not CamelCase friendly.

 The AC_INIT line sets many strings (such as PACKAGE_NAME to FlightGear)
 but not string PACKAGE that is actually set by AM_INIT_AUTOMAKE to
 flightgear. The PACKAGE string is used to derive the tar-ball name.

 There is probably ways around it but I suggest that FlightGear data
 directories are renamed to flightgear. Or follow Curt's --fg-root advice

 As Jari notes, this was an unintentional effect of me updating configure.ac 
 to use the currently-recommened _INIT_ macros for autoconf and automake. My 
 concern was to get the version number encoded in a way that other builds 
 tools besides configure could 'see' - hence the ugly 'm4_esyscmd' trick which 
 is apparently the standard way of accomplishing this.

 Obviously I didn't change the package name when I made the change - it's 
 still 'FlightGear' - but the autoconf docs do state that the package name 
 (eg, for 'make dist' tarbballs) is created by changing this to lowercase, and 
 replacing all non-alphanumeric characters with an underscore. I presume the 
 autoconf maintainers would say this is a feature, but it's subjective :)

 Unfortunately I don't have a solution to restore the old naming scheme - 
 perhaps we can simply override the value of the autoconf PACKAGE variable 
 after invoking AC_INIT? I don't know what other paths and names are derived 
 from this value, and if that will trigger other problems. The path of least 
 resistance would be to accept autoconf's naming scheme, but maybe that's 
 unpalatable.

 Regards,
 James


 --
 Gaining the trust of online customers is vital for the success of any company
 that requires sensitive data to be transmitted over the Web.   Learn how to
 best implement a security strategy that keeps consumers' information secure
 and instills the confidence they need to proceed with transactions.
 http://p.sf.net/sfu/oracle-sfdevnl
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel


--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] 2.2.0 Release branches

2011-01-08 Thread ThorstenB
On Sat, Jan 8, 2011 at 8:44 PM, Roland Haeder wrote:

 I have an FPE to report and a small fix (I already mentioned the FPE in
 IRC chat).

 The fix is included, with some white-space cleanup.

The FPE patch is a duplicate, since Curt has already committed a
similar fix for this FPE on December 20th:
http://www.gitorious.org/fg/flightgear/commit/f8015bf54f5439a9fa70661ac31a10ef8c81f58f

I guess you just need to pull latest GIT.

I'm pushing the other changes with additional include files now. Thanks!

cheers,
Thorsten

--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] 2.2.0 Release branches

2011-01-08 Thread Roland Haeder
Hi Thorsten,

I have reverted my local changes (I didn't locally commit them anyway).
Thanks for including the missing include lines. Jester gave me them in
IRC so please credit him. :)

Regards,
Roland

On Sat, 2011-01-08 at 22:29 +0100, ThorstenB wrote:
 On Sat, Jan 8, 2011 at 8:44 PM, Roland Haeder wrote:
 
  I have an FPE to report and a small fix (I already mentioned the FPE in
  IRC chat).
 
  The fix is included, with some white-space cleanup.
 
 The FPE patch is a duplicate, since Curt has already committed a
 similar fix for this FPE on December 20th:
 http://www.gitorious.org/fg/flightgear/commit/f8015bf54f5439a9fa70661ac31a10ef8c81f58f
 
 I guess you just need to pull latest GIT.
 
 I'm pushing the other changes with additional include files now. Thanks!
 
 cheers,
 Thorsten



signature.asc
Description: This is a digitally signed message part
--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] 2.2.0 Release branches

2011-01-08 Thread ThorstenB
On Sat, Jan 8, 2011 at 10:39 PM, Roland Haeder wrote:

 Thanks for including the missing include lines. Jester gave me them in
 IRC so please credit him. :)

Too late! Sorry Jester, well done anyway :).

cheers,
Thorsten

--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Latest GIT crashes after ~30 min. playtime

2011-01-08 Thread Csaba Halász
On Sat, Jan 8, 2011 at 7:55 PM, Roland Haeder r.hae...@gmx.de wrote:
 Hello all,

 I have a segfault after about 30-40 minutes flight time with both
 optimized and debug build. I flew the A380 the attached flight plan with
 maximum altitude of 15.000ft (not much) from EDDH to LHBP.

 I also included a full backtrace, so please take a look. :)

My guess is you encountered some scenery object that uses particles.
Unfortunately the flight time isn't too helpful in determining your
location at the time of the crash. Maybe you have some additional info
about that? Also, what happens if you disable particles in the
rendering menu. Does the crash also happen if you fly the ufo? Could
try to upgrade OSG as well.

-- 
Cheers,
Csaba/Jester

--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Latest GIT crashes after ~30 min. playtime

2011-01-08 Thread Roland Haeder
With the UFO I got a FPE.

Launch options:

/opt/debug/bin/fgfs --callsign=Quix0r
--multiplay=out,10,mpserver08.flightgear.org,5000
--multiplay=in,10,,5002 --config=/home/quix0r/.fgfs/cockpit-view.xml
--airport=EDDH
--config=/home/quix0r/fgfs/fgfs-base/fgdata/pyromaniac.xml
--control=joystick --aircraft=ufo --log-level=alert --disable-ai-models
--time-match-local --enable-save-on-exit --enable-splash-screen
--enable-fullscreen --disable-game-mode --enable-clouds3d
--enable-horizon-effect --enable-real-weather-fetch --fog-nicest
--enable-textures --enable-specular-highlight --enable-anti-alias-hud
--enable-distance-attenuation --enable-enhanced-lighting --enable-fpe

http://pastebin.com/FqqpFAnm

When I upgrade OSG to higher versions, like 2.9.9 or so I think this is
a pre-release prior 3.0?

Roland

On Sun, 2011-01-09 at 00:05 +0100, Csaba Halász wrote:
 My guess is you encountered some scenery object that uses particles.
 Unfortunately the flight time isn't too helpful in determining your
 location at the time of the crash. Maybe you have some additional info
 about that? Also, what happens if you disable particles in the
 rendering menu. Does the crash also happen if you fly the ufo? Could
 try to upgrade OSG as well.
 



signature.asc
Description: This is a digitally signed message part
--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] A380 Merge Request

2011-01-08 Thread Scott Hamilton


Just wondering if anyone has some time to take a look at this. 
I don't recall seeing anyone saying they had picked it up and haven't
seen anything in fgdata. 
Also I think Jack Mermod had a merge request around the same time for
the AH-1.


  cheers
 S.




On Tue, 2011-01-04 at 16:34 +1100, Scott wrote:

 Greetings and New Year merriment to all,
 
  
 
 After a flurry of activity over the Christmas holiday, could someone
 please commit the latest changes to the A380 in fgdata from;
 
 http://gitorious.org/airbus-aircraft/a380/archive-tarball/master
 
 simply replace all the files and git add the following;
 
 Systems/Electrical/A380-electrical.xml
 Textures/Instruments/buttons4.png
 Textures/Instruments/buttons5.png
 Textures/Instruments/buttons6.png
 
  
 
 Many thanks
 
Scott.
 
  
 
 
 --
 Learn how Oracle Real Application Clusters (RAC) One Node allows customers
 to consolidate database storage, standardize their database environment, and, 
 should the need arise, upgrade to a full multi-node Oracle RAC database 
 without downtime or disruption
 http://p.sf.net/sfu/oracle-sfdevnl
 ___ Flightgear-devel mailing list 
 Flightgear-devel@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel


--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel