Re: [Flightgear-devel] git work flow question

[Anders Gidenstam]

On Tue, 25 Jan 2011, Curtis Olson wrote:

> Once you get it all figured out, please let us know how, so we can get setup
> correctly too. :-)

I'm not sure this counts as figuring it all out.. :)

anders@sleipner:/opt/FlightGear$ du -sk fgdata
7930604 fgdata
anders@sleipner:/opt/FlightGear$ git clone -l fgdata fgdata-test
Cloning into fgdata-test...
done.
anders@sleipner:/opt/FlightGear$ du -sk fgdata fgdata-test/
7930604 fgdata
4614988 fgdata-test/

After checking out the 2.2.0 branch in fgdata-test:

anders@sleipner:/opt/FlightGear$ du -sk fgdata fgdata-test
7934896 fgdata
691112  fgdata-test

A drawback is that the second clone fetches from the first so one would 
need to keep the first uptodate to get the latest commits in the second 
clone. It might be possible to set up fetch and branch tracking to avoid 
that. I'm not sure what happens if both clones fetch new commits from 
gitorious - probably that will lead to duplicate files (fetching from the 
first to the second local repro hopefully doesn't).

Both repositories need to be on the same partition since 
filesystem hardlinks are used.

The use of hardlinks also open up for some confusing du results - 
depending on in which order the files are attributed to directories. :)

anders@sleipner:/opt/FlightGear$ du -sk fgdata/.git fgdata-test/.git
3252104 fgdata/.git
4992fgdata-test/.git
anders@sleipner:/opt/FlightGear$ du -sk fgdata-test/.git fgdata/.git
3246288 fgdata-test/.git
10808   fgdata/.git


Cheers,

Anders
-- 
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Cedric Sodhi]

= IMPORTANT NOTICE TO EVERYONE INVOLVED WITH THE DEVELOPMENT OF FGDATA
OR AIRPLANES THEREIN =

Thanks to the concentrated effort of all people involved, most notably
Jorg - who I'd hereby like to thank on behalf of all of us, for spending
three successive days and nights branching, cloning, filtering,
splitting and verifying data -

FGDATA has, by today, successfully been split

into individual repositories, comprising the respective planes and
FGDATA "core" data.

Again:

=== !!! ===
>From the present day on, the development version of FGDATA NO LONGER
CONTAINS ANY AIRPLANES - You will have to clone a new FGDATA!
===

- Airplanes migrated -

All airplanes, hitherto found in $FGDATA/Aircraft/, have been removed
from that place in the development version of FGDATA and can presently
be found in their individual repositories at the following URL

https://gitorious.org/flightgear-aircraft

(Disclaimer: HTML page is rather huge)

Please contact either of the following administrators to be given
priviledges on one of those repositories:

https://gitorious.org/+flightgear-aircraft/memberships

- New FGDATA Core -

FGDATA is now without any aircraft. The only things which remain in
FGDATA's "Aircraft" directory are general purpose data which are used by
a bulk of different airplanes. The respective directories of these data
are

Generic
Instruments
Instruments-3d

Despite its name, now a historical relict, NO AIRCRAFT SHALL EVER BE
PUSHED TO $FGDATA/Aircraft.

The new FGDATA can be found in the official repository at the following
URL

https://gitorious.org/fg/fgdata-new

The repository is named "fgdata-new" for the time being and the old
"fgdata" is kept arround, frozen, to have a fallback if anything should
happen.

Please contact either of the following administrators to be given
priviledges on the new fgdata repository:

https://gitorious.org/+flightgear-developers/memberships

- Development -

All aircraft related development shall henceforth be performed on
repositories which are maintained by the respective authors.

It is planned that most of the repositories on 

https://gitorious.org/flightgear-aircraft

will be dissolved over time and be taken over by the respective authors.

On a sidenote, some of those repositories are already superflous because
development has long been moved somewhere else. These are the first
repositories which will be decomissioned.

Only repositories for which no author is found will remain stored
centrally.

Development on the rest of FGDATA will continue in the new FGDATA
repository until further notice, possibly until more components are
migrated, as it has been brought forward.

https://gitorious.org/fg/fgdata-new

- Usage -

To keep up with the new structure, commit all your local changes on your
old FGDATA and move its directory out of the way (for example by
renaming it).

$ cd fgdata
$ git commit -a
$ cd ..
$ mv fgdata fgdata-OLD

Next, clone the new repository of FGDATA

$ git clone git://gitorious.org/fg/fgdata-new.git fgdata

IF YOU HAD LOCAL CHANGES, you will need to reapply these changes. This
could be a little adventurous, because these are actually two separate
repositories and you can't just rebase. You'll have to prepare the
patches and apply them over. If you need help with this, check on the
official IRC channel at

irc://irc.flightgear.org/flightgear

for help.

Now you have the new core FGDATA (possibly with your own changes, if you
followed the hint above).

In the coming days, we will provide you with scripts which conveniently
fetch your personal selection of aircrafts; until then you will have to
manually obtain them from the repositories. Here is how:

DO NOT PUT THE AIRCRAFTS INTO THE NEW FGDATA! Instead, create a new
directory somewhere completely different, say,

/usr/local/flightgear/aircrafts

and store the aircrafts in there (for example clone them from their
repositories). If you specify that directory on the command line to
Flightgear, it will find them, altough they are not in the FGDATA
directory. E.g.:

$ ./fgfs --fg-aircraft=/usr/local/flightgear/aircrafts

NOTE: Some aircrafts explicitly require to be inside of FGDATA, because
they are programmed to expect their own data files to be found in
FGDATA. These airplanes will give you an error if you put them outside
of FGDATA (as you must).

In order to solve this, you can symbolically link them individually into
FGDATA (Git is already told to ignore those links).

$ ln -s /usr/local/flightgear/aircrafts/c172p /path/to/fgdata/Aircraft/

===

If you are experiencing problems you can find people who can help you on
IRC.


regards,
ManDay, on behalf of the Split-Team ^^

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and mor

Re: [Flightgear-devel] download_and_compile.sh one git repository or serveral.

[Pat]

I thought there would be a benefit to moving fgdata out from under
${CBD}/install. Currently, if you do mulitple builds with different
options in different folders, you end up with multiple copies of the
same version of fgdata, even though a related build has a perfectly
good copy.


I've got it set up like this:

build/
download_and_compile.sh
    fgdata-2.11.0
    fgdata
    fgdata-2.10.0
    fgdata
master  
install
fgfs
    fgdata symlink

stable
install
fgfs
    fgdata symlink

stable-e
install
fgfs
    fgdata symlink
stable-ei 
etc.

I'm trying this out and will send a patch when its working right.

-Pat

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] git clone -l question and observations

[Curtis Olson]

Here locally I made a local clone of the fgdata repository using "git clone
-l fgdata fgdata-wip".  That seemed to work as advertised.

I noticed that the only branch available in the new local clone "fgdata-wip"
is the branch that is active in fgdata at the time the clone is made 
that's good to know.  It doesn't make a complete clone of ever branch, not
even the master.

I noticed that if I do a "git pull" inside fgdata-wip it *seems* to merge in
changes from the original fgdata respository (master branch) ... I'm not
100% confident in that, I need to try it a few more times after some remote
updates get pushed to the central repository.  I don't know if all the
changes to fgdata/master are brought over, or just the ones that I'm merged
to fgdata/wip after doing a git pull in fgdata/master.  (Isn't this fun,
anyone still with me here?) :-)  At least if I update the branch wip branch
in the oringal fgdata repository, the changes seemed to get brought over to
"fgdata-wip" when I do a pull there.

Now here's my question.  If I make a change inside the cloned wip branch of
the cloned repository "fgdata-wip" and then commit it.  I don't see it show
up in the "wip" branch of the original "fgdata" respository.  It occurred to
me that maybe I need to do a git push to send the changes over to the
original repository, but I get an error that is a lot of git-ese that's way
over my head.

What's the best way to keep my fgdata/wip branch in sync with my
fgdata-clone/wip branch?  Is there a way?

Thanks,

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/>
--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world? 
http://p.sf.net/sfu/oracle-sfdevnlfb___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[dave perry]

On 10/18/2011 10:24 AM, Cedric Sodhi wrote:
> = IMPORTANT NOTICE TO EVERYONE INVOLVED WITH THE DEVELOPMENT OF FGDATA
> OR AIRPLANES THEREIN =
>
> Thanks to the concentrated effort of all people involved, most notably
> Jorg - who I'd hereby like to thank on behalf of all of us, for spending
> three successive days and nights branching, cloning, filtering,
> splitting and verifying data -
>
> FGDATA has, by today, successfully been split
>
> into individual repositories, comprising the respective planes and
> FGDATA "core" data.
>
> Again:
>
> === !!! ===
> > From the present day on, the development version of FGDATA NO LONGER
> CONTAINS ANY AIRPLANES - You will have to clone a new FGDATA!
> =======
>
> - Airplanes migrated -
>
> All airplanes, hitherto found in $FGDATA/Aircraft/, have been removed
> from that place in the development version of FGDATA and can presently
> be found in their individual repositories at the following URL
>
> https://gitorious.org/flightgear-aircraft
>
> (Disclaimer: HTML page is rather huge)
>
> Please contact either of the following administrators to be given
> priviledges on one of those repositories:
>
> https://gitorious.org/+flightgear-aircraft/memberships
>
> - New FGDATA Core -
>
> FGDATA is now without any aircraft. The only things which remain in
> FGDATA's "Aircraft" directory are general purpose data which are used by
> a bulk of different airplanes. The respective directories of these data
> are
>
> Generic
> Instruments
> Instruments-3d
>
> Despite its name, now a historical relict, NO AIRCRAFT SHALL EVER BE
> PUSHED TO $FGDATA/Aircraft.
>
> The new FGDATA can be found in the official repository at the following
> URL
>
> https://gitorious.org/fg/fgdata-new
>
> The repository is named "fgdata-new" for the time being and the old
> "fgdata" is kept arround, frozen, to have a fallback if anything should
> happen.
>
> Please contact either of the following administrators to be given
> priviledges on the new fgdata repository:
>
> https://gitorious.org/+flightgear-developers/memberships
>
> - Development -
>
> All aircraft related development shall henceforth be performed on
> repositories which are maintained by the respective authors.
>
> It is planned that most of the repositories on
>
> https://gitorious.org/flightgear-aircraft
>
> will be dissolved over time and be taken over by the respective authors.
I don't understand the above (up to - Development -).

Questions:
1.  Are you saying that aircraft developers cannot leave their aircraft in

https://gitorious.org/flightgear-aircraft

indefinitely?  So do we need to set up our own git repository for each 
ac we maintain?  This raises the knowledge/experience bar required for 
aircraft developers/maintainers.

2.  Assuming the answers are no, yes, to #1, will all these repositories 
be centrally located so one can track new or modified ac of interest?

3.  Is there any interest in creating repositories by ac class/type?  
e.g. historical, military-fighter, military-transport, 
civilian-light-ac, airliners, etc.

By the way, thanks for all the work on this and also for this helpful 
note of documentation!


> On a sidenote, some of those repositories are already superflous because
> development has long been moved somewhere else. These are the first
> repositories which will be decomissioned.
>
> Only repositories for which no author is found will remain stored
> centrally.
>
> Development on the rest of FGDATA will continue in the new FGDATA
> repository until further notice, possibly until more components are
> migrated, as it has been brought forward.
>
> https://gitorious.org/fg/fgdata-new
>
> - Usage -
>
> To keep up with the new structure, commit all your local changes on your
> old FGDATA and move its directory out of the way (for example by
> renaming it).
>
> $ cd fgdata
> $ git commit -a
> $ cd ..
> $ mv fgdata fgdata-OLD
>
> Next, clone the new repository of FGDATA
>
> $ git clone git://gitorious.org/fg/fgdata-new.git fgdata
>
> IF YOU HAD LOCAL CHANGES, you will need to reapply these changes. This
> could be a little adventurous, because these are actually two separate
> repositories and you can't just rebase. You'll have to prepare the
> patches and apply them over. If you need help with this, check on the
> official IRC channel at
>
> irc://irc.flightgear.org/flightgear
>
> for help.
>
> Now you have the new core FGDATA (possibly with your own changes, if you
> followed the hint above).
>
> In the coming days, we will provide you with scripts which conveniently
> fetch your pe

Re: [Flightgear-devel] .."IP" and litigation risks, was: AH-1 Merge Request

[Heiko Schulz]

Hi,
Technically, all these logos are under trademark:
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/737-100/Models/Liveries/731CA.png;h=43cfc5a15abb392519e1f95d34951d410d3c3c80;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/737-100/Models/Liveries/731continw.png;h=2c7854e28f50ebfd270551fea6ee17c161ca56a6;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/747-400/Models/Liveries/KLM.png;h=fb5a5e15737ff7d45cb4b6c4ecae1c664221fd4c;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/767-300/Models/ACA.png;h=24cab3acc9be66ffa819d4b86b3d269d6c5c146d;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/767-300/Models/AFR.png;h=feb509950de44037ee2ffe72d99e803820f2078c;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/767-300/Models/ANZ.png;h=6ac933fa22c33e0f0b637c032cdc473108fee367;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/767-300/Models/AUA.png;h=6fa2d4d95c4e614bb67b
a3514a09d60b253e45d7;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/767-300/Models/BAW.png;h=c13d743667bf7de26df391ee1baf6627f012ae9b;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/767-300/Models/UAL.png;h=5c93dbbe501aa1a44adbaeac305e4a637ff8adec;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/777-200/Models/DAL-Livery.png;h=e516842b15c4cd8e42c3f20dd2bbd9e1cfcebb8e;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/777-200/Models/KLM.png;h=76ca78871b1b5cd58eb0533aefc91eb63b5e7149;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/ec135/Models/fuselage.adac.png;h=effa8b73133ad6991dc615ea670b5a3db58dcc0e;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/ec135/Models/fuselage.anwb.png;h=f4ca4abcc551aeca443ca68b06f60006ef84af12;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/ZivkoEdge/Models/Liveries/Fuse
lage-RedBull.png;h=4af09d1cb79a04528b824447190bc68e809ecceb;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/ZivkoEdge/Models/Liveries/WingTail-RedBull.png;h=592707498df5f8f923b2c9da1f3e9a68370ddd7e;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/Zlin-50lx/Models/Liveries/red-bull.png;h=d60378d6af8635efc3f5b15a1345e2a810f65fcb;hb=HEAD
I can dish out links all day if I have to




I surprised that you mentioned ADAC and ANWB. Both are known that they won't 
give any problems.
Problem is more the Eurocopter-logo which I should better remove. 
I hope I find some time tomorrow to do that.


The problem is, Jack, and that's something it seems to me you didn't 
understand: 
The problem is really only the Red Bull logo, as they are known to make 
problems. If other sims use this logo, then only because Red Bull didn't 
discoverd it yet.
Mostly all other logos using in this sim are known not to be a problem. 


Cheers
Heiko



--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Building FlightGear under Vista

[Jon S. Berndt]

> When I built OSG (from the latest SVN ) using  Cmake  I did not include
> tiff
> libraries. The net result was a similar error message to yours when I
> tried
> to use a tiff texture file. Also all my panels were white.
> 
> I replaced the tiff file with a png equivalent (as used by many FG
> aircraft
> models) and both the error message disappeared and my cockpit textures
> re-appeared.
> 
> Hence my reply. It may be that an OSG plugin may be the solution under
> Linux/Cygwin, but with Windows the option was required at OSG�s
> Cmake/compilation time .
> 
> Alan


OK, I tried this again under a Windows command window. Even after copying all 
of the dlls, etc., into the FlightGear executable directory, I still get tons 
of errors, until finally getting a core dump (see below). I do have all of the 
OSG DLLs, OpenAL, etc., which were installed during the process.

I have a sneaking suspicion that somehow I do not have my paths (PATH 
environment variable, or whatever) set up correctly. Is there an easy way to 
check that? I do see that there is an osgPlugin-2.9.7/ subdirectory under the 
OpenSceneGraph/bin/ directory. Is that supposed to be in the PATH, as well? I 
added it, but it seemed to have no effect.

Jon


C:\cygwin\home\jon\flightgear>FlightGear\projects\VC90\Win32\Release\fgfs 
--fg-root=c:\cygwin\home\jon\flightgear\fgdata
Processing command line arguments
using aircraft-dir 
for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/c172p/splash.png
Warning: Could not find plugin to read objects from file 
"c:/cygwin/home/jon/flightgear/fgdata/Aircraft/c172p/splash.png".
Warning: Could not find plugin to read objects from file 
"c:/cygwin/home/jon/flightgear/fgdata/Fonts/Helvetica.txf".
... etc. ...
using aircraft-dir 
for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/c172p/c172-sound.xml
using aircraft-dir 
for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/c172p/Models/c172p.xml
Failed to load model: Failed to load 3D model:
from:Aircraft/c172p/Models/c172p.xml
Warning: Could not find plugin to read objects from file 
"C:\cygwin\home\jon\flightgear\fgdata\Textures\Sky\overcast.png".
... etc. ...
Warning: Could not find plugin to read objects from file 
"C:\cygwin\home\jon\flightgear\fgdata\Textures\Sky\outer_halo.png".
using FG_ROOT 
for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/Generic/generic-systems.xml
using FG_ROOT 
for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/Generic/Panels/generic-vfr-panel.xml
using FG_ROOT 
for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/Generic/Panels/Textures/panel-bg.rgb
Warning: Could not find plugin to read objects from file 
"c:/cygwin/home/jon/flightgear/fgdata/Aircraft/Generic/Panels/Textures/panel-bg.rgb".
using FG_ROOT 
for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/Generic/Panels/Textures/generic-panel-01.rgb
... etc. ...
Warning: Could not find plugin to read objects from file 
"c:/cygwin/home/jon/flightgear/fgdata/Fonts/typewriter.txf".
using FG_ROOT 
for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/Instruments/Textures/od_wxradar.rgb
... etc. ...
init contrail
*** NEW LOCATION ***
Loading local weather routines...
using aircraft-dir 
for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/c172p/Nasal/liveries.nas
... etc. ...
using aircraft-dir 
for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/c172p/Nasal/ki266.nas
KI266 dme indicator #0 initialized
using aircraft-dir 
for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/c172p/Nasal/c172-electrical.nas
using FG_ROOT 
for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/Generic/kap140.nas
using aircraft-dir 
for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/c172p/Nasal/kr87.nas
loading scenario 'nimitz_demo'
creating 3D noise texture... DONE
failed to load effect texture file 
C:\cygwin\home\jon\flightgear\fgdata\Textures\Terrain\water.png
... etc. ...
failed to load effect texture file 
C:\cygwin\home\jon\flightgear\fgdata\Textures\Terrain\water-lake.png
Failed to load model: Failed to load 3D model:
from:Models/Maritime/Civilian/ContainerShip.xml
Failed to load model: Failed to load 3D model:
    from:Models/Maritime/Civilian/SailBoatUnderSail.xml
failed to load effect texture file 
C:\cygwin\home\jon\flightgear\fgdata\Textures\Trees\coniferous-summer.png
Failed to load model: Failed to load 3D model:
    from:Models/Communications/radio-medium.xml
failed to load effect texture file 
C:\cygwin\home\jon\flightgear\fgdata\Textures.high\Terrain\deciduous1.png
... etc. ...
Failed to load object Models/Buildings/factory.ac

*** segfault here ***





--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] .."IP" and litigation risks, was: AH-1 Merge Request

[Jack Mermod]

Hi,

Technically, all these logos are under trademark:

http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/737-100/Models/Liveries/731CA.png;h=43cfc5a15abb392519e1f95d34951d410d3c3c80;hb=HEAD
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/737-100/Models/Liveries/731continw.png;h=2c7854e28f50ebfd270551fea6ee17c161ca56a6;hb=HEAD
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/747-400/Models/Liveries/KLM.png;h=fb5a5e15737ff7d45cb4b6c4ecae1c664221fd4c;hb=HEAD
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/767-300/Models/ACA.png;h=24cab3acc9be66ffa819d4b86b3d269d6c5c146d;hb=HEAD
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/767-300/Models/AFR.png;h=feb509950de44037ee2ffe72d99e803820f2078c;hb=HEAD
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/767-300/Models/ANZ.png;h=6ac933fa22c33e0f0b637c032cdc473108fee367;hb=HEAD
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/767-300/Models/AUA.png;h=6fa2d4d95c4e614bb67ba3514a09d60b253e45d7;hb=HEAD
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/767-300/Models/BAW.png;h=c13d743667bf7de26df391ee1baf6627f012ae9b;hb=HEAD
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/767-300/Models/UAL.png;h=5c93dbbe501aa1a44adbaeac305e4a637ff8adec;hb=HEAD
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/777-200/Models/DAL-Livery.png;h=e516842b15c4cd8e42c3f20dd2bbd9e1cfcebb8e;hb=HEAD
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/777-200/Models/KLM.png;h=76ca78871b1b5cd58eb0533aefc91eb63b5e7149;hb=HEAD
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/ec135/Models/fuselage.adac.png;h=effa8b73133ad6991dc615ea670b5a3db58dcc0e;hb=HEAD
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/ec135/Models/fuselage.anwb.png;h=f4ca4abcc551aeca443ca68b06f60006ef84af12;hb=HEAD
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/ZivkoEdge/Models/Liveries/Fuselage-RedBull.png;h=4af09d1cb79a04528b824447190bc68e809ecceb;hb=HEAD
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/ZivkoEdge/Models/Liveries/WingTail-RedBull.png;h=592707498df5f8f923b2c9da1f3e9a68370ddd7e;hb=HEAD
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/Zlin-50lx/Models/Liveries/red-bull.png;h=d60378d6af8635efc3f5b15a1345e2a810f65fcb;hb=HEAD

I can dish out links all day if I have to


And go ahead, get them removed. ;) You know what you'll have  
accomplished when you're finished? You'll have deleted hundreds of  
hours of work, all in paranoia of a lawsuit that will never happen.


Unless you wish to delete nearly all our liveries, all of you that do  
not wish for my work to be committed are being well, hypocrites.



On the subject of my AH-1; I have removed the content for now, what  
other hoops do you want me to jump through? I'd like to see somebody  
commit it relatively soon, so my (somewhat) recent work can be  
included in the release.



Check Six,
 Jack--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Building FlightGear under Vista

[Frederic Bouvier]

 Please post the result of the "set PATH" command (under Windows prompt,
not cygwin)

As said in the updated instructions, you must also have the 3rdParty/bin
directory in your path as well

To diagnose DLL loading problems, Dependency Walker is your friend.

-Fred

Le 05/09/2010 18:04, Jon S. Berndt a écrit :
>> When I built OSG (from the latest SVN ) using  Cmake  I did not include
>> tiff
>> libraries. The net result was a similar error message to yours when I
>> tried
>> to use a tiff texture file. Also all my panels were white.
>>
>> I replaced the tiff file with a png equivalent (as used by many FG
>> aircraft
>> models) and both the error message disappeared and my cockpit textures
>> re-appeared.
>>
>> Hence my reply. It may be that an OSG plugin may be the solution under
>> Linux/Cygwin, but with Windows the option was required at OSG�s
>> Cmake/compilation time .
>>
>> Alan
>
> OK, I tried this again under a Windows command window. Even after copying all 
> of the dlls, etc., into the FlightGear executable directory, I still get tons 
> of errors, until finally getting a core dump (see below). I do have all of 
> the OSG DLLs, OpenAL, etc., which were installed during the process.
>
> I have a sneaking suspicion that somehow I do not have my paths (PATH 
> environment variable, or whatever) set up correctly. Is there an easy way to 
> check that? I do see that there is an osgPlugin-2.9.7/ subdirectory under the 
> OpenSceneGraph/bin/ directory. Is that supposed to be in the PATH, as well? I 
> added it, but it seemed to have no effect.
>
> Jon
>
>
> C:\cygwin\home\jon\flightgear>FlightGear\projects\VC90\Win32\Release\fgfs 
> --fg-root=c:\cygwin\home\jon\flightgear\fgdata
> Processing command line arguments
> using aircraft-dir 
> for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/c172p/splash.png
> Warning: Could not find plugin to read objects from file 
> "c:/cygwin/home/jon/flightgear/fgdata/Aircraft/c172p/splash.png".
> Warning: Could not find plugin to read objects from file 
> "c:/cygwin/home/jon/flightgear/fgdata/Fonts/Helvetica.txf".
> ... etc. ...
> using aircraft-dir 
> for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/c172p/c172-sound.xml
> using aircraft-dir 
> for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/c172p/Models/c172p.xml
> Failed to load model: Failed to load 3D model:
> from:Aircraft/c172p/Models/c172p.xml
> Warning: Could not find plugin to read objects from file 
> "C:\cygwin\home\jon\flightgear\fgdata\Textures\Sky\overcast.png".
> ... etc. ...
> Warning: Could not find plugin to read objects from file 
> "C:\cygwin\home\jon\flightgear\fgdata\Textures\Sky\outer_halo.png".
> using FG_ROOT 
> for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/Generic/generic-systems.xml
> using FG_ROOT 
> for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/Generic/Panels/generic-vfr-panel.xml
> using FG_ROOT 
> for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/Generic/Panels/Textures/panel-bg.rgb
> Warning: Could not find plugin to read objects from file 
> "c:/cygwin/home/jon/flightgear/fgdata/Aircraft/Generic/Panels/Textures/panel-bg.rgb".
> using FG_ROOT 
> for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/Generic/Panels/Textures/generic-panel-01.rgb
> ... etc. ...
> Warning: Could not find plugin to read objects from file 
> "c:/cygwin/home/jon/flightgear/fgdata/Fonts/typewriter.txf".
> using FG_ROOT 
> for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/Instruments/Textures/od_wxradar.rgb
> ... etc. ...
> init contrail
> *** NEW LOCATION ***
> Loading local weather routines...
> using aircraft-dir 
> for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/c172p/Nasal/liveries.nas
> ... etc. ...
> using aircraft-dir 
> for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/c172p/Nasal/ki266.nas
> KI266 dme indicator #0 initialized
> using aircraft-dir 
> for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/c172p/Nasal/c172-electrical.nas
> using FG_ROOT 
> for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/Generic/kap140.nas
> using aircraft-dir 
> for:c:/cygwin/home/jon/flightgear/fgdata/Aircraft/c172p/Nasal/kr87.nas
> loading scenario 'nimitz_demo'
> creating 3D noise texture... DONE
> failed to load effect texture file 
> C:\cygwin\home\jon\flightgear\fgdata\Textures\Terrain\water.png
> ... etc. ...
> failed to load effect texture file 
> C:\cygwin\home\jon\flightgear\fgdata\Textures\Terrain\water-lake.png
> Failed to load model: Failed to load 3D model:
> from:Models/Maritime/Civilian/ContainerShip.xml
> Failed to load model: Failed to load 3D model:
> from:Models/Mar

Re: [Flightgear-devel] git work flow question

[Curtis Olson]

The other implication here is that it would be extremely handy to have
multiple branches checked out simultaneously for other reasons.  git makes
branching easy, yes, but if you find yourself bouncing between branches with
changes for separate projects, and external events may require you to jump
to a different branch at a moments notice, It's a major PITA to have to
commit every little thing you are in the middle of to switch to another
branch.

This is like having to completely clean up your desk before you can work on
a new task, and then clean it up again completely before you can jump to the
next.  I just don't work like that, I bounce between about 12 desktops, 40
browser tabs, multiple coding projects.

And then when someone pushes something to the remote repository, you have to
clean up the desk again, switch to the master branch, do a pull, and then
individually switch to each of your local branches and do a merge.  Tedious
to say the least, and intrusive to the continuity of my work flow!  I know
where everything is on my desk ... if you make me clean it up and put it all
away 10 times a day ... yeah I have a spotless desk, but I can't actually
get anything done!

Hope that didn't sound too much like a vent, still trying to figure out how
to merge the git view of the world with my own, and I'm still not entirely
happy. :-)

I'll definitely have to checkout the local checkout feature.  Do we
understand the branching/merging nuances in this case?  Will I need to do a
git pull in the master branch for each locally cloned repository or will the
hard links ensure that a git pull in one repository is reflected in all the
others ... no I suppose not, since the local clones are clones of the first
repository ... we'll probably need to still do individual git pulls in each
of them (from the master branch) to update them ... so still lots of branch
switching and manual fiddling to maintain these local branches.  Hmmm.

Curt.


On Tue, Jan 25, 2011 at 3:16 PM, Anders Gidenstam
wrote:

> On Tue, 25 Jan 2011, Curtis Olson wrote:
>
> > Once you get it all figured out, please let us know how, so we can get
> setup
> > correctly too. :-)
>
> I'm not sure this counts as figuring it all out.. :)
>
> anders@sleipner:/opt/FlightGear$ du -sk fgdata
> 7930604 fgdata
> anders@sleipner:/opt/FlightGear$ git clone -l fgdata fgdata-test
> Cloning into fgdata-test...
> done.
> anders@sleipner:/opt/FlightGear$ du -sk fgdata fgdata-test/
> 7930604 fgdata
> 4614988 fgdata-test/
>
> After checking out the 2.2.0 branch in fgdata-test:
>
> anders@sleipner:/opt/FlightGear$ du -sk fgdata fgdata-test
> 7934896 fgdata
> 691112  fgdata-test
>
> A drawback is that the second clone fetches from the first so one would
> need to keep the first uptodate to get the latest commits in the second
> clone. It might be possible to set up fetch and branch tracking to avoid
> that. I'm not sure what happens if both clones fetch new commits from
> gitorious - probably that will lead to duplicate files (fetching from the
> first to the second local repro hopefully doesn't).
>
> Both repositories need to be on the same partition since
> filesystem hardlinks are used.
>
> The use of hardlinks also open up for some confusing du results -
> depending on in which order the files are attributed to directories. :)
>
> anders@sleipner:/opt/FlightGear$ du -sk fgdata/.git fgdata-test/.git
> 3252104 fgdata/.git
> 4992fgdata-test/.git
> anders@sleipner:/opt/FlightGear$ du -sk fgdata-test/.git fgdata/.git
> 3246288 fgdata-test/.git
> 10808   fgdata/.git
>
>
> Cheers,
>
> Anders
> --
> ---
> Anders Gidenstam
> WWW: http://www.gidenstam.org/FlightGear/
>
>
> --
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> ___
> 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/>
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an e

Re: [Flightgear-devel] fgdata trouble

[Geoff McLane]

On Sat, 2012-09-22 at 19:44 +, Martin Spott wrote:
> "Alan Teeder" wrote:
> 
> > New flightgear git users are faced with an initial download of about 10gb 
> > just to get started.
> 
> Currently the "fgdata" GIT repo has approx. 4.9 GByte,
> 
>   Martin.

Hi Martin, Alan, Bertrand, et al...

I guess we each have a 'different' way of measuring 
things ;=))

This is back on Sep 1, and it grows every day...

/media/Disk2/FG/fg20$ dirdate fgdata
Processed 9130 directories, 59899 files, 11,281,006,933 bytes.
Latest   : fgdata/.git/index 2012/08/01 16:08:21, of 59899 files.

/media/Disk2/FG/fg20$ dirsize fgdata
Doing du -b -s fgdata... moment...
Total of [fgdata] = 11,298,718,037 bytes (10.52GB)

Ok, now I know some MORE git commands that reduce this 
on disk size, thanks Bertrand, 
$ git repack
$ git gc
$ git prune
but that does not stop the initial download into 
fgdata/.git

/media/Disk2/FG/fg20/fgdata$ dirsize .git
Doing du -b -s .git... moment...
Total of [.git] = 4,419,875,575 bytes (4.12GB)

It seems a shame all the discussion I saw about 
somehow splitting this 4-5GB download came to 
nothing ;=((

It seems 'some' absolutely wanted to keep a single git 
command to get it ALL... while I would see no trouble in 
a simple clean split... like -

$ git clone  fgdata
$ cd fgdata
$ git clone  Aircraft

/media/Disk2/FG/fg20/fgdata$ dirsize Aircraft
Doing du -b -s Aircraft... moment...
Total of [Aircraft] = 5,879,186,664 bytes (5.48GB)
so assume the .git portion of this would be 
similarly about half...

But that does not stop the BIG initial downloads, 
just splits it into 2, so perhaps better -
$ git clone  fgdata
also includes a dozen or so Aircraft, like the 
windows release packages...

Then I go somewhere else to ADD Aircraft, when, if 
I want... 

Perhaps a nice little GUI app, that lets me choose 
which aircraft I want to add... maybe does a download 
of a zip file, and continues to unzip it into -
/fgdata/Aircraft

Something I think Pete was working on...

Or into a 'separate' folder since I think we do 
now support multiple 'aircraft' directories, or 
should if we don't...

And it would be nice if that app could also download 
from other people's 'hangars'...

So you can see I am strongly with Alan on this... 
this topic needs to be continued, and resolved...

BTW, my makefg script also frequently FAILS on 
fgdata - clone or pull... So much so that I usually now 
always do that manually... seems git does not like to 
be 'managed' in a script...

Regards,
Geoff.



--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] .."IP" and litigation risks, was: AH-1 Merge Request

[Michael Sgier]

i doubt...have a look at FSX. Even commercial products alike xtraffic etc use 
such liveries.

--- On Thu, 2/17/11, Jack Mermod  wrote:

From: Jack Mermod 
Subject: Re: [Flightgear-devel] .."IP" and litigation risks, was: AH-1 Merge 
Request
To: "Devel List" 
Date: Thursday, February 17, 2011, 3:45 AM

Hi,
Technically, all these logos are under trademark:
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/737-100/Models/Liveries/731CA.png;h=43cfc5a15abb392519e1f95d34951d410d3c3c80;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/737-100/Models/Liveries/731continw.png;h=2c7854e28f50ebfd270551fea6ee17c161ca56a6;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/747-400/Models/Liveries/KLM.png;h=fb5a5e15737ff7d45cb4b6c4ecae1c664221fd4c;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/767-300/Models/ACA.png;h=24cab3acc9be66ffa819d4b86b3d269d6c5c146d;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/767-300/Models/AFR.png;h=feb509950de44037ee2ffe72d99e803820f2078c;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/767-300/Models/ANZ.png;h=6ac933fa22c33e0f0b637c032cdc473108fee367;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/767-300/Models/AUA.png;h=6fa2d4d95c4e614bb67b
a3514a09d60b253e45d7;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/767-300/Models/BAW.png;h=c13d743667bf7de26df391ee1baf6627f012ae9b;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/767-300/Models/UAL.png;h=5c93dbbe501aa1a44adbaeac305e4a637ff8adec;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/777-200/Models/DAL-Livery.png;h=e516842b15c4cd8e42c3f20dd2bbd9e1cfcebb8e;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/777-200/Models/KLM.png;h=76ca78871b1b5cd58eb0533aefc91eb63b5e7149;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/ec135/Models/fuselage.adac.png;h=effa8b73133ad6991dc615ea670b5a3db58dcc0e;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/ec135/Models/fuselage.anwb.png;h=f4ca4abcc551aeca443ca68b06f60006ef84af12;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/ZivkoEdge/Models/Liveries/Fuse
lage-RedBull.png;h=4af09d1cb79a04528b824447190bc68e809ecceb;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/ZivkoEdge/Models/Liveries/WingTail-RedBull.png;h=592707498df5f8f923b2c9da1f3e9a68370ddd7e;hb=HEADhttp://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/Zlin-50lx/Models/Liveries/red-bull.png;h=d60378d6af8635efc3f5b15a1345e2a810f65fcb;hb=HEAD
I can dish out links all day if I have to

And go ahead, get them removed. ;) You know what you'll have accomplished when 
you're finished? You'll have deleted hundreds of hours of work, all in paranoia 
of a lawsuit that will never happen.
Unless you wish to delete nearly all our liveries, all of you that do not wish 
for my work to be committed are being well, hypocrites.

On the subject of my AH-1; I have removed the content for now, what other hoops 
do you want me to jump through? I'd like to see somebody commit it relatively 
soon, so my (somewhat) recent work can be included in the release.

Check Six,                 Jack
-Inline Attachment Follows-

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
-Inline Attachment Follows-

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



  --
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git

[Anders Gidenstam]

On Thu, 29 Sep 2011, Frederic Bouvier wrote:

> If you cloned the official data repository on your own machine, you 
> won't be allowed to push anything.
>
> What you have to do is to clone the repository in your own 
> gitorious.org project and then clone that clone on your own machine. As 
> it is your own project, you will be able to push into it and then submit 
> merge requests.

Now, before anyone unnecessarily goes through the pain of cloning fgdata 
again, you just need to add the git URL to your new personal 
clone at gitorious as a remote in your local fgdata clone to be able to 
push to gitorious.

For example:

git remote add g...@gitorious.org:~andersg/fg/anders-fgdata.git my-fgdata

Stores the URL to my fgdata clone at gitorious under the name my-fgdata in 
my local git clone of fgdata. (You want the gitorious SSH URL for your 
repository)


git push my-fgdata my-branch:master

Pushes the local branch named my-branch to my-fgdata (i.e. my clone of 
fgdata at gitorious) where the branch will be named master.

Cheers,

Anders
-- 
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FGData Split Completed

[Cedric Sodhi]

Hello everybody,

I apologize if my initial mail did not describe it clearly enough. I
hope this mail helps with all of your questions:

Before you go on a disclaimer ahead: There has been a minor (not just in
a manner of speaking) complication with the new FGDATA repository, so
there is now a new-new fgdata repository (which has that minor issue
rectified, although the old-new fgdata was perfectly usuable aswell).

We are currently doing the final reviews on the new-new fgdata and that
should be the fgdata to pull, once everything is verified.

There are the following repositories now:



fgdata

an2
14bis
21
707
717
727-230
737-100
737-200
737-300
737ng600
737ng700
737ng800
737ng900
747
...etc...

=

The first repository is the plain fgdata which everyone will need to
clone. It will sit in the place where the current fgdata (with all the
airplaines) sits and replace that. For that, you will have to move the
old fgdata to a place elsewhere. And if you don't have any local
branches on it, you can already delete it.

If you have local changes, you will have to prepare patches between
current master-tip and your local branch-tip, and apply these patches to
the new fgdata master-tip.

The following repositories are the aircrafts. You will have to clone
every aircraft which you would like to have as a git repository. And you
should clone them into a different directory than fgdata (strongly
recommented).

If you want all aircraft, you will have to clone all aircraft.

These are the simple facts.

-

For your convenience, here is a script which pulls and updates all
aircrafts from our central repository which you would like to have.

In order to use it, you need to create a textfile into which you put the
names of all aircrafts which you would like to have. Each name into its
own line. Example

-
an2
21
747
b29
-

Then you run this script like this

$ ./fgaircrafts  

Example:

$ ./fgaircrafts list.txt /usr/local/flightgear/aircraft

Those aircrafts which have already been cloned will be pulled, those
which are not yet there will be cloned.

Note: The script operates on the repositories in parallel, so don't
expect any readable output on the commandline.

[Flightgear-devel] ..both fgdata mirrors still gives me the same good old un-split fgdata?

[Arnt Karlsen]

Hi,


..does both git clone git://gitorious.org/fg/fgdata.git and
git clone git://mapserver.flightgear.org/fgdata still give 
us the same good old un-split fgdata?

..I found them slightly different: ...
Cloning into fgdata...
remote: Counting objects: 171405, done.
remote: Compressing objects: 100% (66543/66543), done.
^Carnt@nb6:~/FG-git$ 1% (19898/171405), 191.00 MiB | 48 KiB/s
arnt@nb6:~/FG-git$ ./download_and_compile.sh -s -a n -p n -j 2 DATA
**
**
* Warning, the compilation process   *
* is going to use 9 or more Gbytes   *
* of space and at least a couple of  *
* hours to download and build FG.*
**
* Please, be patient ..  *
**
**

 FGFS **

Cloning into fgdata...
remote: Counting objects: 171402, done.
remote: Compressing objects: 100% (70966/70966), done.

...especially speedwise. ;o) 

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
--- /home/arnt/Downloads/download_and_compile.sh	2011-11-02 22:30:53.0 +0100
+++ download_and_compile.sh	2011-11-02 22:14:18.0 +0100
@@ -731,7 +731,9 @@
 			then
 EXDIR=$(pwd)
 cd $INSTALL_DIR_FGFS
-echo -n "GIT DATA FROM git://gitorious.org/fg/fgdata.git ... " >> $LOGFILE
+# echo -n "GIT DATA FROM git://gitorious.org/fg/fgdata.git ... " >> $LOGFILE
+# 
+echo -n "GIT DATA FROM git clone git://mapserver.flightgear.org/fgdata ... " >> $LOGFILE
 #cvs -z5 -d :pserver:cvsguest:gu...@cvs.flightgear.org:/var/cvs/FlightGear-0.9 login
 #cvs -z5 -d :pserver:cvsgu...@cvs.flightgear.org:/var/cvs/FlightGear-0.9 co data
 
@@ -740,7 +742,9 @@
 	echo "fgdata exists already."
 else
 	# no repository yet - need to clone a fresh one
-	git clone git://gitorious.org/fg/fgdata.git
+	# git clone git://gitorious.org/fg/fgdata.git
+					# 
+	git clone git://mapserver.flightgear.org/fgdata
 fi
 
 cd fgdata
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] New alpha version of download_and_compile.sh - avoids multiple fgdata downloads.

[Arnt Karlsen]

On Fri, 21 Jun 2013 07:03:19 -0400, Pat wrote in message 
<20130621070319.43455586@spinnaker01>:

> I've put a new version of download_and_compile.sh on the team clone 
> 
> http://www.gitorious.org/+fg-download-and-compile/fg/fg-download-and-compile-fgmeta/blobs/next/download_and_compile.sh
> 
> The big change:
> 
>   This version changes the way fgdata is handled to prevent
>   multiple downloads of the 5G of git archives for fgdata.
>   Multiple versions of fgdata can be kept active and up to date
>   for testing purposes.  Various build and install trees can be
>   created using download_and_compile.sh. Each of these will use
>   symlinks to the appropriate fgdata version.
> 
> This is an alpha version 
> 
>   It has not been approved for the main tree.
> 
>   It has had some testing, but needs others to try it out to
>   uncover any bugs.  I recommend using it in a separate
> directory from your usual builds until you have some confidence in
> how it works.  
> 
> If you find a bug, create a detailed log by running it like this:
> 
>   ./download_and_compile.sh -xv
> >download_and_compile_diagnostics.log
> 
>   This log is likely to be large.  Please don't e-mail it to the
>   list.
> 
>   Instead, Email me, find me on irc #flightgear as user pac1 or
>   contact me through the flightgear forum.  If you've got my
>   phone #, feel free to use it.
> 
> Here's the commit note for the change:
> 
> Add -D option to change the handling of fgdata
> 
>   With this change a download_and_compile.sh user can optionally
>   use a single copy of fgdata as a base for builds using any
>   other version.
> 
>   The -D option will find and create if not found, version
>   directories for fgdata.  Once this is done for one version,
>   download_and_compile.sh will use these directories to prevent
>   multiple downloads of the entire 5gb git archive, when a
>   different version of fgdata is needed.  The directories are
>   initially placed at the same level as download_and_compile.sh.
>   The directories can be moved higher in the directory tree if
>   desired.
> 
>   When an existing or new build and install tree needs to use a
>   particular version of fgdata, a symlink in fgfs/install will
>   connect the build to the correct version.  If the correct
>   version does not yet exist it will be copied from an existing
>   fgdata of another version and changed to the needed version
>   using git checkout.
> 
>   This allows download_and_compile.sh to create as many build
> and install trees as desired, each with different versions and
>   options, while keeping network usage to a minimum.
> 
>   a typical set of fgdata and separate build directories  might
>   look like:
> 
>   ~/work/fg
>   ~/work/fg/fgdata_2.8.0
>   ~/work/fg/fgdata_2.10.0
>   ~/work/fg/fgdata_2.11.0
>   ~/work/fg/master
>   ~/work/fg/master-openrti-debug
>   ~/work/fg/stable
>   ~/work/fg/2.10.0-debug
> 
>   for each build, the required symlink will be created to the
>   corresponding fgdata_* directory.

..to avoid the 3-day delay fetching a new 5GB copy of fgdata, 
where do I put my "March 29'th-current" copy of fgdata?
I now have it as 2.11.0 in ~/FG-git/fgdata 

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Stuart Buchanan]

On Tue, Oct 18, 2011 at 5:33 PM, Stuart Buchanan wrote:
> On Tue, Oct 18, 2011 at 5:24 PM, Cedric Sodhi wrote:
>> NOTE: Some aircrafts explicitly require to be inside of FGDATA, because
>> they are programmed to expect their own data files to be found in
>> FGDATA. These airplanes will give you an error if you put them outside
>> of FGDATA (as you must).
>>
>> In order to solve this, you can symbolically link them individually into
>> FGDATA (Git is already told to ignore those links).
>>
>> $ ln -s /usr/local/flightgear/aircrafts/c172p /path/to/fgdata/Aircraft/
>>
>> ===
>
> Surely that would be a bug in the aircraft that should be fixed?

... and it has now been. You should now be able to use the c172p outside
of the fgdata/ directory.

-Stuart

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Torsten Dreyer]

Am 18.10.2011 18:24, schrieb Cedric Sodhi:
> Next, clone the new repository of FGDATA
>
> $ git clone git://gitorious.org/fg/fgdata-new.git fgdata
For some reason, there seems to be no ssh url available for fgdata-new 
and the aircraft projects?

Torsten

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Building FlightGear under Vista

[Jon S. Berndt]

> Start a Windows command prompt and the command line should be something
> like
> 
> $ FlightGear/projects/VC90/Win32/Release/fgfs --fg-
> root=c:/cygwin/home/jon/flightgear/fgdata/
> 
> Anyway, you can use forward slash, but must have a drive letter at the
> start.
> Found version [none] means there is no base package at the path
> specified, more likely because the
> path is not understood
> 
> -Fred

That helped, but now I am getting different errors:

--- start ---
$ FlightGear/projects/VC90/Win32/Release/fgfs 
--fg-root=c:/cygwin/home/jon/flightgear/fgdata/
Processing command line arguments
using aircraft-dir 
for:c:/cygwin/home/jon/flightgear/fgdata//Aircraft/c172p/splash.png
Warning: Could not find plugin to read objects from file 
"c:/cygwin/home/jon/flightgear/fgdata//Aircraft/c172p/splash.png".
Warning: Could not find plugin to read objects from file 
"c:/cygwin/home/jon/flightgear/fgdata//Fonts/Helvetica.txf".
Warning: Could not find plugin to read objects from file 
"c:/cygwin/home/jon/flightgear/fgdata//Fonts/Helvetica.txf".
Warning: Could not find plugin to read objects from file 
"c:/cygwin/home/jon/flightgear/fgdata//Fonts/Helvetica.txf".
using aircraft-dir 
for:c:/cygwin/home/jon/flightgear/fgdata//Aircraft/c172p/c172-sound.xml
using aircraft-dir 
for:c:/cygwin/home/jon/flightgear/fgdata//Aircraft/c172p/Models/c172p.xml
Failed to load model: Failed to load 3D model:
from:Aircraft/c172p/Models/c172p.xml
...
--- end ---

Yet all of the plugins are clearly accessible. For example,

which osg2cpp

Yields:

/home/jon/flightgear/install/msvc90/OpenSceneGraph/bin/osg2cpp

The cygwin bash command line recognizes the path, but it seems that FlightGear 
may not recognize the path. How does this work in Linux?

Jon




--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] git of fgdata today

[Donn Washburn]

On 12/23/2010 01:14 PM, Torsten Dreyer wrote:
> Am 23.12.10 19:35, schrieb Donn Washburn:
>> On 12/23/2010 12:24 PM, Gijs de Rooy wrote:
>>>> FGDATA site seems to be down or have problems.  I have tried about 5
>>>> times over time to get fgdata with the same error.
>>> Gitorious was down since earlier today. However, it appears to be up
>>> again now.
>>>
>>> You can still obtain fgdata from the mapserver clone though, if
>>> Gitorious still doesn't
>>> work: http://mapserver.flightgear.org/git/?p=fgdata;a=summary
>>>
>>> Cheers,
>>> Gijs
>> Thanks that seems to be working. It even seems faster
Now that I have the most recent fgdata I am still seeing an error.  I have no 
clue on this error.

just using the default - ./fgfs  I get this error.

Base package check failed ... Found version [none] at: @PKGLIBDIR
Please upgrade to version: 2.0.0

I have fgdata in a directory /usr/share/flightgear.Anyone have clue.

I have about every known SVN/GIT version of fgfs, fgdata, plib, openGL, 
freeglut, freealut, OSG and simgear.
I am also running NV.run

07 Savoy Street Email:" n5...@comcast.net "
Sugar Land, TX 77478 LL# 1.281.242.3256
Ham Callsign N5XWB   HAMs : " n5...@arrl.net "
VoIP via Gizmo: bmw_87kbike / via Skype: n5xwbg
BMW MOA #: 4146 - Ambassador
   " http://counter.li.org " #279316


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

Re: [Flightgear-devel] Aircraft issues: Vostok-1, (dc-3, dhc6, CRJ700, pa24-250-CIIB)

[Anders Gidenstam]

On Sat, 7 Jan 2012, thorsten.i.r...@jyu.fi wrote:

>> Thorsten, can you make a test flight and see if the instruments behave as
>> they used to?
>
>
>>> To try it get the vostok-1 branch from my fgdata clone:
>>> git://gitorious.org/~andersg/fg/anders-fgdata.git
>
> If you tell me how to pull only Vostok from your fgdata? I have a GSM
> connection from home and not too much bandwidth... and my GIT knowledge is
> still rather limited.

Ah, sorry. It is actually in fgdata now. So you only need to update 
fgdata. (Hmm.. depending on how recent your local fgdata is that could be 
expensive, though.)

To pull that branch you'd run

git fetch git://gitorious.org/~andersg/fg/anders-fgdata.git vostok-1:vostok-1

The download would not be huge as you'd only need to fetch those commits 
that weren't present in your local fgdata repository.


However, if your fgdata is far behind HEAD you can also just apply the 
important change by hand:

diff --git a/Aircraft/Vostok-1/Systems/Enginespanel.xml 
b/Aircraft/Vostok-1/Syst
index cabc0b9..9faa671 100644
--- a/Aircraft/Vostok-1/Systems/Enginespanel.xml
+++ b/Aircraft/Vostok-1/Systems/Enginespanel.xml
@@ -13,6 +13,19 @@
  Enginespanel 
 

+   
+   
+   
+   
+   
+   simulation/sim-time-sec GT 0.1
+   
+   
+   
+
  

Re: [Flightgear-devel] fgdata version in master branch

[Frederic Bouvier]

Hi Robert,

> De: "Robert"

> Hi everybody,

> since one or two weeks I have the following problem:
> When I start fgfs it tells me that it needs version 2.7.0 of fgdata
> and quits immediately.
> I am using SimGear/Flightgear "next" branch, and fgdata "master"
> branch.
> After maually changing the version-file in fgdata from 2.5.0 to 2.7.0
> everything is okay.
> It would be nice if someone could change the version number to 2.7.0
> in the "master" branch.

Already done for awhile. See yourself :
https://gitorious.org/fg/fgdata/blobs/master/version
https://gitorious.org/fg/fgdata/commit/49283115c5042d42c68939b2942eeda7760df5fc

Regards,
-Fred

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] New alpha version of download_and_compile.sh - avoids multiple fgdata downloads.

[Pat]

I've put a new version of download_and_compile.sh on the team clone 

http://www.gitorious.org/+fg-download-and-compile/fg/fg-download-and-compile-fgmeta/blobs/next/download_and_compile.sh

The big change:

This version changes the way fgdata is handled to prevent
multiple downloads of the 5G of git archives for fgdata.
Multiple versions of fgdata can be kept active and up to date
for testing purposes.  Various build and install trees can be
created using download_and_compile.sh. Each of these will use
symlinks to the appropriate fgdata version.

This is an alpha version 

It has not been approved for the main tree.

It has had some testing, but needs others to try it out to
uncover any bugs.  I recommend using it in a separate directory
from your usual builds until you have some confidence in how it
works.  

If you find a bug, create a detailed log by running it like this:

./download_and_compile.sh -xv >download_and_compile_diagnostics.log

This log is likely to be large.  Please don't e-mail it to the
list.

Instead, Email me, find me on irc #flightgear as user pac1 or
contact me through the flightgear forum.  If you've got my
phone #, feel free to use it.

Here's the commit note for the change:

Add -D option to change the handling of fgdata

With this change a download_and_compile.sh user can optionally
    use a single copy of fgdata as a base for builds using any
other version.

The -D option will find and create if not found, version
    directories for fgdata.  Once this is done for one version,
download_and_compile.sh will use these directories to prevent
multiple downloads of the entire 5gb git archive, when a
    different version of fgdata is needed.  The directories are
initially placed at the same level as download_and_compile.sh.
The directories can be moved higher in the directory tree if
desired.

When an existing or new build and install tree needs to use a
    particular version of fgdata, a symlink in fgfs/install will
connect the build to the correct version.  If the correct
version does not yet exist it will be copied from an existing
fgdata of another version and changed to the needed version
using git checkout.

This allows download_and_compile.sh to create as many build and
install trees as desired, each with different versions and
options, while keeping network usage to a minimum.

    a typical set of fgdata and separate build directories  might
look like:

~/work/fg
~/work/fg/fgdata_2.8.0
~/work/fg/fgdata_2.10.0
~/work/fg/fgdata_2.11.0
~/work/fg/master
~/work/fg/master-openrti-debug
~/work/fg/stable
~/work/fg/2.10.0-debug

for each build, the required symlink will be created to the
corresponding fgdata_* directory.

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Nasal submodules / local weather

[ThorstenB]

Hi Thorsten (& all),

some time ago I had added an option to introduce Nasal submodules, or,
to be more exact, to introduce Nasal modules using fgdata/Nasal/...
subdirectories and add an option to load such modules on demand only
(using a single enable/disable property per module).

This has several advantages:
* Nasal files can be grouped neatly instead of all scripts being mixed
up in a single fgdata/Nasal directory. Grouping makes a lot of sense for
modules consisting of several scripts - local weather is the best
example.
* Guaranteed loading sequence. Submodules are loaded _after_ the main
fgdata/Nasal scripts, so they can rely on all fgdata/Nasal content to be
already present. No more need for awkward listener callbacks, just to
make sure that basic "props" or "gui" modules are available.
* Finally, users have the option to disable loading modules.
Unfortunately, just loading scripts (code/data) into memory already
causes certain _run-time_ performance effects - even if the Nasal code
was never executed (so even when all listeners/timers were disabled).

Admittedly, I'm concerned that the rising number of complex Nasal
modules degrades the simulation performance for everyone. Having an
option to disable modules completely seems a good idea, so everyone can
choose for himself. And when something is not even loaded, it's
naturally guaranteed that it cannot have any performance effects at all.

I'd like to use the local weather module as a good example here. I'm
planning to do the same with a few other modules (tutorial.nas,
jetways*.nas, maybe multiplayer, and the new Nasal Boeing CDU).

I've done some tests with a "local weather submodule" and it seems fine.
Few modifications are required - mainly affects the init handlers (need
to listen to a different signal) and some GUI aspects (add an option to
enable/load the Nasal module, enable/disable menu items). I've attached
the changes. Before applying the patch, move the existing weather
scripts into a new subdirectory "Nasal/local_weather":

# create new subdirectory "local_weather"
mkdir fgdata/Nasal/local_weather

# move existing files to new directory
mv fgdata/Nasal/compat_layer.nas fgdata/Nasal/local_weather/.
mv fgdata/Nasal/weather_dynamics.nas fgdata/Nasal/local_weather/.
mv fgdata/Nasal/weather_tiles.nas fgdata/Nasal/local_weather/.
mv fgdata/Nasal/local_weather.nas fgdata/Nasal/local_weather/.
mv fgdata/Nasal/weather_tile_management.nas fgdata/Nasal/local_weather/.

# apply patch (attached)
cd fgdata && patch -p1 < local_weather.patch

I'd like to push the change to fgdata before the release. Please test if
you're happy with these changes - or let me know if you saw issues.

cheers,
Thorsten

diff --git a/Nasal/local_weather/compat_layer.nas b/Nasal/local_weather/compat_layer.nas
index 0fbd8e4..4605aed 100644
--- a/Nasal/local_weather/compat_layer.nas
+++ b/Nasal/local_weather/compat_layer.nas
@@ -67,8 +67,19 @@
 # The compatibility layer is currently work in progress and will be extended as new Nasal 
 # APIs are being added to FlightGear.
 
+var weather_dynamics = nil;
+var weather_tile_management = nil;
+var compat_layer = nil;
+var weather_tiles = nil;
+
+
+_setlistener("/nasal/local_weather/loaded", func { 
+
+compat_layer = local_weather;
+weather_dynamics = local_weather;
+weather_tile_management = local_weather;
+weather_tiles = local_weather;
 
-_setlistener("/sim/signals/nasal-dir-initialized", func { 
 
 var result = "yes";
 
diff --git a/Nasal/local_weather/local_weather.nas b/Nasal/local_weather/local_weather.nas
index 52c7a2f..eecb95a 100644
--- a/Nasal/local_weather/local_weather.nas
+++ b/Nasal/local_weather/local_weather.nas
@@ -4414,10 +4414,18 @@ setprop(lw~"tiles/tile-counter",0);
 
 setprop(lwi~"ipoint-number",0);
 
+var updateMenu = func {
+	var isEnabled = getprop("/nasal/local_weather/enabled");
+	gui.menuEnable("local_weather", isEnabled);
+	gui.menuEnable("local_weather_tiles", isEnabled);
+}
+
+_setlistener("/nasal/local_weather/enabled", updateMenu);
 
 # wait for Nasal to be available and do what is in startup()
 
-_setlistener("/sim/signals/nasal-dir-initialized", func {
+_setlistener("/nasal/local_weather/loaded", func {
+	updateMenu();
 	startup();
 });
 
diff --git a/gui/dialogs/local_weather_config.xml b/gui/dialogs/local_weather_config.xml
index 5826cff..f72bb54 100644
--- a/gui/dialogs/local_weather_config.xml
+++ b/gui/dialogs/local_weather_config.xml
@@ -6,10 +6,22 @@
 
  local_weather_config
  400
- 400
+ 440
  false
 
 
+
+   5
+   400
+   15
+   15
+   Enable local weather module
+   /nasal/local_weather/enabled
+   
+dialog-apply
+   
+
+
 
   5
   370
diff --git a/gui/menubar.xml b/gui/menubar.xml
index bbaa69a..fba2618 100644
--- a/gui/menubar.xml
+++ b/gui/menubar.xml
@

Re: [Flightgear-devel] Building FlightGear under Vista

[Jon S. Berndt]

> That helped, but now I am getting different errors:
> 
> --- start ---
> $ FlightGear/projects/VC90/Win32/Release/fgfs --fg-
> root=c:/cygwin/home/jon/flightgear/fgdata/
> Processing command line arguments
> using aircraft-dir
> for:c:/cygwin/home/jon/flightgear/fgdata//Aircraft/c172p/splash.png
> Warning: Could not find plugin to read objects from file
> "c:/cygwin/home/jon/flightgear/fgdata//Aircraft/c172p/splash.png".
> Warning: Could not find plugin to read objects from file
> "c:/cygwin/home/jon/flightgear/fgdata//Fonts/Helvetica.txf".
> Warning: Could not find plugin to read objects from file
> "c:/cygwin/home/jon/flightgear/fgdata//Fonts/Helvetica.txf".
> Warning: Could not find plugin to read objects from file
> "c:/cygwin/home/jon/flightgear/fgdata//Fonts/Helvetica.txf".
> using aircraft-dir
> for:c:/cygwin/home/jon/flightgear/fgdata//Aircraft/c172p/c172-sound.xml
> using aircraft-dir
> for:c:/cygwin/home/jon/flightgear/fgdata//Aircraft/c172p/Models/c172p.x
> ml
> Failed to load model: Failed to load 3D model:
> from:Aircraft/c172p/Models/c172p.xml
> ...
> --- end ---
> 
> Yet all of the plugins are clearly accessible. For example,
> 
> which osg2cpp
> 
> Yields:
> 
> /home/jon/flightgear/install/msvc90/OpenSceneGraph/bin/osg2cpp
> 
> The cygwin bash command line recognizes the path, but it seems that
> FlightGear may not recognize the path. How does this work in Linux?
> 
> Jon

I even went to a Windows command shell and got the same results. What is
FlightGear looking for, and why can it not find it?

Jon



--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Nonfunctional airplanes

[thorsten . i . renk]

>> fgdata, but while git status lists a couple of files as having
>> differences, that are files I know should be different because I changed
>> them. No aircraft is listed as being different.
>
> The inter-dependencies in the Base Package between seemlingly unrelated
> pieces have grown _that_ much, that you'd probably better start from a
> clean checkout (have a backup of your customized files  ;-)

Hm, wiping fgdata and reinstalling seems to have made the Lightning fly
again - nice.

Problem is - I have no clue why, or what I did wrong with my fgdata
management.

I get fgdata by unpacking a bundle, followed by an update, i.e.

git clone fgdata.bundle fgdata
cd fgdata
git checkout -b master origin/master

followed by

git pull git://gitorious.org/fg/fgdata.git master

inside fgdata/ which I repeat every now and then, after which files are
transferred and I did definitely observe some changes (in the shaders for
instance).

I did (naively perhaps) change some files inside fgdata, and indeed

git status

gave a list of precisely those files as out of sync - which didn't really
worry me. But evidence suggests that in fact a lot more was not updated
for whatever reason.

So what did I do wrong, and what should I do differently in the future?

* Thorsten


--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Building FlightGear under Vista

[Jon S. Berndt]

> On Sat, 4 Sep 2010, Jon S. Berndt wrote:
> 
> > Which directory should one be under when they execute the git
> command?
> 
> Hi,
> 
> You should be in the directory where you want to have the fgdata
> directory, i.e. git creates fgdata in the current directory.
> Cloning will download about 2.5GB of data so it will take a good while.
> If gitorious is slow you can also clone from
> http://mapserver.flightgear.org/git/fgdata
> 
> > Is there anything that needs to be done afterwards when the data is
> all
> > downloaded, or is FlightGear ready to run at that point?
> 
> FlightGear should be ready to run at that point. Use the
> --fg-root=/path/to/fgdata
> argument to point FlightGear to the fgdata directory - it probably
> won't
> find it otherwise.
> 
> Cheers,
> 
> Anders


Here's how I ran FlightGear, but it did not like the command:

$ FlightGear/projects/VC90/Win32/Release/fgfs
--fg-root=/home/jon/flightgear/fgdata/


Base package check failed ... Found version [none] at:
/home/jon/flightgear/fgdata/
Please upgrade to version: 2.0.0
Hit a key to continue...

I just downloaded the base package today as directed via git.

What am I doing wrong?

Jon



--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git of fgdata today

[Gijs de Rooy]

> FGDATA site seems to be down or have problems.  I have tried about 5 
> times over time to get fgdata with the same error.

Gitorious was down since earlier today. However, it appears to be up again now.

You can still obtain fgdata from the mapserver clone though, if Gitorious still 
doesn't
work: http://mapserver.flightgear.org/git/?p=fgdata;a=summary

Cheers,
Gijs  --
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

Re: [Flightgear-devel] use-custom-scenery-data

[Alex B.]

Ahoy Martin,

thanks for replying, but let me rephrase my initial questions.

No. 1)
Durk wrote[1]: "[...]and the files that are still called "parking" are
the ones that I still need to rename / improve / verify." There are
still files called "parking" in the base package. Maybe someone will
rename / improve / verify them before the 2.4.0 release. I even do
volunteer for this job if I'd only know what to do and if there is no
nasal or C++ coding involved.

find $fgdata/Scenery/ -name *parking*
$fgdata/Scenery/Airports/K/H/W/KHWD.parking.xml
$fgdata/Scenery/Airports/K/H/A/KHAF.parking.xml
$fgdata/Scenery/Airports/K/O/A/KOAK.parking.xml
$fgdata/Scenery/Airports/K/S/F/KSFO.parking.xml
$fgdata/Scenery/Airports/K/S/J/KSJC.parking.xml


No. 2)
Never mind, I'll just ignore that one. ;-)


Griassla
Alex

[1] http://sourceforge.net/mailarchive/message.php?msg_id=24237463

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT

[Martin Spott]

Christian Schmitt wrote:

> As I already wrote here yesterday, the fgdata repo needs currently 
> approx 1GB of diskspace on my machine here.

This is a bit surprising, as the repository _without_ checkout should
have approximately this size:

hypersphere: 15:58:01 ~> du -hs git/fgdata/ GIT/fgdata/
1,1Ggit/fgdata/
2,7GGIT/fgdata/


The bigger one contains the repo itself _plus_ the checkout,

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

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Stuart Buchanan]

Good work guys. Thanks.

On Tue, Oct 18, 2011 at 5:24 PM, Cedric Sodhi wrote:
> NOTE: Some aircrafts explicitly require to be inside of FGDATA, because
> they are programmed to expect their own data files to be found in
> FGDATA. These airplanes will give you an error if you put them outside
> of FGDATA (as you must).
>
> In order to solve this, you can symbolically link them individually into
> FGDATA (Git is already told to ignore those links).
>
> $ ln -s /usr/local/flightgear/aircrafts/c172p /path/to/fgdata/Aircraft/
>
> ===

Surely that would be a bug in the aircraft that should be fixed?

Also, IIRC there are a number of aircraft that have dependencies on other
aircraft. Presumably this would be a good opportunity to fix those as well?

-Stuart

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Building FlightGear under Vista

[Frederic Bouvier]

Jon,

- "Jon S. Berndt" a écrit :

> > On Sat, 4 Sep 2010, Jon S. Berndt wrote:
> > 
> > > Which directory should one be under when they execute the git
> > command?
> > 
> > Hi,
> > 
> > You should be in the directory where you want to have the fgdata
> > directory, i.e. git creates fgdata in the current directory.
> > Cloning will download about 2.5GB of data so it will take a good
> while.
> > If gitorious is slow you can also clone from
> > http://mapserver.flightgear.org/git/fgdata
> > 
> > > Is there anything that needs to be done afterwards when the data
> is
> > all
> > > downloaded, or is FlightGear ready to run at that point?
> > 
> > FlightGear should be ready to run at that point. Use the
> > --fg-root=/path/to/fgdata
> > argument to point FlightGear to the fgdata directory - it probably
> > won't
> > find it otherwise.
> > 
> > Cheers,
> > 
> > Anders
> 
> 
> Here's how I ran FlightGear, but it did not like the command:
> 
> $ FlightGear/projects/VC90/Win32/Release/fgfs
> --fg-root=/home/jon/flightgear/fgdata/
> 
> 
> Base package check failed ... Found version [none] at:
> /home/jon/flightgear/fgdata/
> Please upgrade to version: 2.0.0
> Hit a key to continue...
> 
> I just downloaded the base package today as directed via git.
> 
> What am I doing wrong?

Start a Windows command prompt and the command line should be something like

$ FlightGear/projects/VC90/Win32/Release/fgfs 
--fg-root=c:/cygwin/home/jon/flightgear/fgdata/

Anyway, you can use forward slash, but must have a drive letter at the start.
Found version [none] means there is no base package at the path specified, more 
likely because the
path is not understood

-Fred

-- 
Frédéric Bouvier
http://my.fotolia.com/frfoto/  Photo gallery - album photo
http://www.youtube.com/user/fgfred64   Videos


--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git clone -l question and observations

[Curtis Olson]

No one has answered yet which makes me guess (a) I didn't ask very well or
(b) no one knows the answer, so let me try again here.

I created a local clone of my fgdata repository using the --local option
which builds hard links to the master original repository and saves lots of
space.  The clone repository has one branch ... the one that was active in
the source repository when I made the clone.

When others push changes to the gitorious fgdata.git repository, I can then
do a "git pull" in my "master" branch of my primary local fgdata repository.
 Then I can switch to a branch in my master repository (git checkout) and
run "git merge master" to merge the changes from the master branch into my
local branch and keep the local branch in sync with everyone
else's development work.

This is all done in the original clone from gitorious.  None of this affects
or alters my local clone repository with its mirror of a local branch.
 However, I can go over to that local clone and run "git pull" (after I've
merged the changes to the same branch in the master repository) and all
those changes from the source branch get merged over into my local copy
branch.  So git seems to be aware of the connection between the branch in my
primary gitorious clone and the same branch in my --local clone.

Here is what I can't figure out.

If I make changes in my --local clone branch and commit them, they are there
in the local clone, but don't show up in the same branch in the original
gitorious clone repository.  It seems like it would make sense to run "git
push" after "git commit" in my --local clone branch, but that produces an
error:

$ git push
Counting objects: 33, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (22/22), done.
Writing objects: 100% (22/22), 2.79 KiB, done.
Total 22 (delta 14), reused 0 (delta 0)
Unpacking objects: 100% (22/22), done.
remote: error: refusing to update checked out branch: refs/heads/drone-f-14b
remote: error: By default, updating the current branch in a non-bare
repository
remote: error: is denied, because it will make the index and work tree
inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to
match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration
variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing
into
remote: error: its current branch; however, this is not recommended unless
you
remote: error: arranged to update its work tree to match what you pushed in
some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour,
set
remote: error: 'receive.denyCurrentBranch' configuration variable to
'refuse'.
To /home/curt/Projects/FlightGear/fgdata
 ! [remote rejected] drone-f-14b -> drone-f-14b (branch is currently checked
out)
error: failed to push some refs to '/home/curt/Projects/FlightGear/fgdata'

Does anyone understand what I am trying to do here?  Am I trying to solve
the wrong problem?  Is there a way to go forward here and keep my two copies
of my branch in sync?  Am I lost beyond the fringes of "git kludge" land?
 :-)  What's the point of creating a --local clone if you can't push the
changes back into your main repository? ... especially when you have to
leverage the matching mirrror in the main repository to keep your --local
branch in sync with upstream changes?

Thanks,

Curt.


On Sat, Feb 5, 2011 at 1:19 PM, Curtis Olson  wrote:

> Here locally I made a local clone of the fgdata repository using "git clone
> -l fgdata fgdata-wip".  That seemed to work as advertised.
>
> I noticed that the only branch available in the new local
> clone "fgdata-wip" is the branch that is active in fgdata at the time the
> clone is made  that's good to know.  It doesn't make a complete clone of
> ever branch, not even the master.
>
> I noticed that if I do a "git pull" inside fgdata-wip it *seems* to merge
> in changes from the original fgdata respository (master branch) ... I'm not
> 100% confident in that, I need to try it a few more times after some remote
> updates get pushed to the central repository.  I don't know if all the
> changes to fgdata/master are brought over, or just the ones that I'm merged
> to fgdata/wip after doing a git pull in fgdata/master.  (Isn't this fun,
> anyone still with me here?) :-)  At least if I update the branch wip branch
> in the oringal fgdata repository, the changes seemed to get brought over to
> "fgdata-wip" when I do a pull there.
>
> Now here's my question.  If I make a change inside the cloned wip branch of
> the cl

Re: [Flightgear-devel] git clone -l question and observations

[Curtis Olson]

Ok, I think I figured this out.  The clue was in the error message I posted.
 I had the branch in question checked out in my main repository clone, so
the system couldn't push changes from my --local clone of the branch back
into that branch in the primary clone.

I guess that makes some sort of sense ... it avoids (reduces?) the chance of
problems pushing the changes if there are competing/conflicting changes in
the other copy of the branch.

This is almost worth a facebook status update. :-)  I just updated my
--local clone branch, made  some changes, and pushed them back into the
primary branch!   :-)

So any time someone pushes a change to the gitorious repository here is the
approximate procedure to update my local clones/branches (this is the git
replacement for the old cvs update command):

cd "primary-fgdata"
git pull
 - oops I have a branch checked out currently
git checkout master
 - oops commit any changes in the current branch
 - git diff
 - git commit
git checkout master (try again, it works)
git pull (now it works)
git checkout "primary-branch"
git merge master (to sync the upstream changes with my own "wip" branch)

But this is just in the main fgdata clone, Now cd over to my --local branch
clone.

cd "../fgdata-clone"
git pull (merge upstream changes from my local master repository that have
been merged into the master branch in the previous step.)
git diff (see what I changed locally)
git commit (commit my local changes)
git push (push these changes back into the primary branch in my original
clone of the gitoriious repository)
 - oops I have the branch checked out in my primary local  repository
- cd "../fgdata-primary"
- git checkout master
 - cd ../fgdata-clone"
git push (now it works!)

Woohoo, everything should now be consistent and in sync and all the upstream
changes should be fully merged.

Ok, so this is how I keep all my branches up to date here when ever anyone
pushes a change to the upstream gitorious repository.  Isn't that so much
superior to a one-line "cvs update" command which all this replaces ?!?!?
:-) :-) :-)

Curt.



On Sun, Feb 6, 2011 at 10:44 AM, Curtis Olson wrote:

> No one has answered yet which makes me guess (a) I didn't ask very well or
> (b) no one knows the answer, so let me try again here.
>
> I created a local clone of my fgdata repository using the --local option
> which builds hard links to the master original repository and saves lots of
> space.  The clone repository has one branch ... the one that was active in
> the source repository when I made the clone.
>
> When others push changes to the gitorious fgdata.git repository, I can then
> do a "git pull" in my "master" branch of my primary local fgdata repository.
>  Then I can switch to a branch in my master repository (git checkout) and
> run "git merge master" to merge the changes from the master branch into my
> local branch and keep the local branch in sync with everyone
> else's development work.
>
> This is all done in the original clone from gitorious.  None of this
> affects or alters my local clone repository with its mirror of a local
> branch.  However, I can go over to that local clone and run "git pull"
> (after I've merged the changes to the same branch in the master repository)
> and all those changes from the source branch get merged over into my local
> copy branch.  So git seems to be aware of the connection between the branch
> in my primary gitorious clone and the same branch in my --local clone.
>
> Here is what I can't figure out.
>
> If I make changes in my --local clone branch and commit them, they are
> there in the local clone, but don't show up in the same branch in the
> original gitorious clone repository.  It seems like it would make sense to
> run "git push" after "git commit" in my --local clone branch, but that
> produces an error:
>
> $ git push
> Counting objects: 33, done.
> Delta compression using up to 2 threads.
> Compressing objects: 100% (22/22), done.
> Writing objects: 100% (22/22), 2.79 KiB, done.
> Total 22 (delta 14), reused 0 (delta 0)
> Unpacking objects: 100% (22/22), done.
> remote: error: refusing to update checked out branch:
> refs/heads/drone-f-14b
> remote: error: By default, updating the current branch in a non-bare
> repository
> remote: error: is denied, because it will make the index and work tree
> inconsistent
> remote: error: with what you pushed, and will require 'git reset --hard' to
> match
> remote: error: the work tree to HEAD.
> remote: error:
> remote: error: You can set 'receive.denyCurrentBranch' configuration
> variable to
> remote: error: 'ignore' or 'warn' in the re

[Flightgear-devel] Scripted Installation - An update and a summary of where things stand.

[Pat]

Lets review where things stand with the script:



Current commit on team clone:
 download_and_compile.shAug 31 2013 #58ae270 Version
 1.9.12 (Pat)

http://www.gitorious.org/fg/fg-download-and-compile-fgmeta/raw/58ae27079531e69ec48c6df06538559680bd9433:download_and_compile.sh

Contains a fix to a bug found and reported by Arnt.

Additional testing is needed before this can be merged to the main
fgmeta.

A detailed list of the changes in the script version
1.9.12 can be found here:

http://www.gitorious.org/fg/fg-download-and-compile-fgmeta/commit/58ae27079531e69ec48c6df06538559680bd9433
Francesco approved an early version of 1.9.12. There have been
additional small changes made.  

-Pat




For Arnt and others interested in where things are going, the following
summarizes a lot of stuff that's already been said here and elsewhere.

The current "official" script in fgmeta is 1.9.11 
It builds 2.8.0 as stable and will build next. It would need small
modifications to build 1.9.10 or 1.9.12 

Arnt has requested details on any new design for the directory
structure.  I've given one below, but I'm open to suggestions if you'd
prefer something different.

Here are the design goals:

1.  download_and_compile.sh continues to work exactly as it has in the
past.  It will continue to use the same directory structure unless
the user decides to take an action that causes a new directory
structure to be adopted for subsequent builds.

2.  Minimize the impact on git and svn servers by removing the need to
download multiple copies of sources and data.

3.  Facilitate testing the script with different versions and options.

To meet these goals there are several features being added to the
script.  Some of these are partially in place, some will require
additional changes.

Changes through script version 1.9.12:
=== === == === ===

1. Terminal Window Titles

2. Additional versions of OSG supported

3. Support for any branch, including the soon to be released flightgear
   2.12.0.  2.10.0 is considered stable at this point in time.

4. Use manually placed fgdata copies in the parent of the build
   directory.  

   Copies of fgdata git repositories can be placed in directories
   named fgdata_2.8.0, fgdata_2.10.0, fgdata_2.12.0 and fgdata_2.99.9. 
   
   If download_and_compile.sh is run from a sub-directory of the 
   directory containing the fgdata* directories, instead of downloading 
   a separate copy of fgdata, the script will simply create s symbolic
   link to the correct fgdata git copy.  

   Note that initially all the copies' versions do not have to match
   the directory name.  Any recent version of fgdata will do.  When it
   runs, the script will update the version you are building to be the
   correct version of fgdata.

   This approach to keeping multiple fgdata versions 
   means you never have to download fgdata more than once.  

1. You can blow away a build and not have to redownload fgdata
2. You can have multiple variant builds of a single version all
   using the same fgdata_*/fgdata version
3. You can build different versions of flightgear and still not
   have to download another fgdata

== 
Future Changes:
== 


1. Change the directory structure for sources to allow a single copy of
   the sources to be used for multiple versions and variants without
   having to download the sources repeatedly.

   Similarly to the placement of the fgdata_* copies, create new
   directories for sources: 

fgsrc
which will contain sources for anything native to
flightgear
othersrc 
which will contain sources for plib and as many
versions of OSG as you need.

Builds will be done in a subdirectory, one per variant

It will look something like:

download_and_compile.sh

    fgdata_2.10.0
    fgdata
    fgdata 2.12.0
    fgdata
    fgdata 2.99.9
fgdata
fgsrc
flightgear
simgear
openrti
fgcom (unless we abandon the separate fgcom)
fgrun
etc.
othersrc
OpenSceneGraph-3.0.1
OpenSceneGraph-3.1.9

plib-1.8.5

variant-2.12.0-openrti
build
install
compilation_log.txt

variant-2.10.0-noopenrti
build
install
compilation_log.txt

variant-master-openrti
variant-master-noopenrti
variant-next-noopenrti
variant-next-noopenrti
and so forth.


Note that with 1.9.12 and later its possible to build the
master branch.

Usage:

cd variant-master-openrti
../download_and_compile.sh [option

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Cedric Sodhi]

On Tue, Oct 18, 2011 at 05:33:23PM +0100, Stuart Buchanan wrote:
> On Tue, Oct 18, 2011 at 5:24 PM, Cedric Sodhi wrote:
> > NOTE: Some aircrafts explicitly require to be inside of FGDATA, because
> > they are programmed to expect their own data files to be found in
> > FGDATA. These airplanes will give you an error if you put them outside
> > of FGDATA (as you must).
> >
> > In order to solve this, you can symbolically link them individually into
> > FGDATA (Git is already told to ignore those links).
> >
> > $ ln -s /usr/local/flightgear/aircrafts/c172p /path/to/fgdata/Aircraft/
> >
> > ===
> 
> Surely that would be a bug in the aircraft that should be fixed?
> 
Indeed.

> Also, IIRC there are a number of aircraft that have dependencies on other
> aircraft. Presumably this would be a good opportunity to fix those as well?
> 
Agreed.

ManDay

> -Stuart


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] File sizes in fgdata, clean up needed?

[HB-GRAL]

Am 18.03.11 20:00, schrieb ThorstenB:
>
> Indeed, fgdata/master is becoming way too big though. But we can only
> solve this by splitting our current repository - and then push the
> different parts to fresh git repositories. Splitting fgdata was planned
> anyway. The new "--fg-aircraft" options was the first step to make this
> possible. I'm just not sure what the status of splitting fgdata is though...
>
> cheers,
> Thorsten
>

Splitting is a good idea, sorry I didn’t realize that this is on the way 
right now. I "splitted" fgdata locally today because I want to 
distribute a snapshot of my new OSX launcher (FlightGear 2.2 for 10.5/6 
intel) with some basic fgdata included, for testing purposes. Now "fgx 
full" comes with very basic fgdata around 800 MB. The .dmg to download 
takes ~500 MB. From the aircrafts I only included

737-100
b1900d
bo105
c172p
Citation-Bravo
Concorde
ec135
followme
Generic
Instruments
Instruments3d
MPCarrier
Pushback
seahawk
Sikorsky-76C
Storch
ufo
UH-1
wrightFlyer1903
ZLT-NT

I am looking forward to include a better selection. I just wanted to 
have a good selection for a starting point with "working" aircrafts and 
a good mix of types. Maybe you see something important missing here, but 
when a new (and probably well discussed) repo with "default fg 
aircrafts" comes around, I will switch to this selection of course.

Thanks, Yves


--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Building FlightGear under Vista

[Frederic Bouvier]

try to remove the trailing slash, or use fgrun that is in the official 2.0.0 
package

-Fred

- "Jon S. Berndt"  a écrit :

> > That helped, but now I am getting different errors:
> > 
> > --- start ---
> > $ FlightGear/projects/VC90/Win32/Release/fgfs --fg-
> > root=c:/cygwin/home/jon/flightgear/fgdata/
> > Processing command line arguments
> > using aircraft-dir
> > for:c:/cygwin/home/jon/flightgear/fgdata//Aircraft/c172p/splash.png
> > Warning: Could not find plugin to read objects from file
> > "c:/cygwin/home/jon/flightgear/fgdata//Aircraft/c172p/splash.png".
> > Warning: Could not find plugin to read objects from file
> > "c:/cygwin/home/jon/flightgear/fgdata//Fonts/Helvetica.txf".
> > Warning: Could not find plugin to read objects from file
> > "c:/cygwin/home/jon/flightgear/fgdata//Fonts/Helvetica.txf".
> > Warning: Could not find plugin to read objects from file
> > "c:/cygwin/home/jon/flightgear/fgdata//Fonts/Helvetica.txf".
> > using aircraft-dir
> >
> for:c:/cygwin/home/jon/flightgear/fgdata//Aircraft/c172p/c172-sound.xml
> > using aircraft-dir
> >
> for:c:/cygwin/home/jon/flightgear/fgdata//Aircraft/c172p/Models/c172p.x
> > ml
> > Failed to load model: Failed to load 3D model:
> > from:Aircraft/c172p/Models/c172p.xml
> > ...
> > --- end ---
> > 
> > Yet all of the plugins are clearly accessible. For example,
> > 
> > which osg2cpp
> > 
> > Yields:
> > 
> > /home/jon/flightgear/install/msvc90/OpenSceneGraph/bin/osg2cpp
> > 
> > The cygwin bash command line recognizes the path, but it seems that
> > FlightGear may not recognize the path. How does this work in Linux?
> > 
> > Jon
> 
> I even went to a Windows command shell and got the same results. What
> is
> FlightGear looking for, and why can it not find it?
> 
> Jon
> 
> 
> 
> --
> This SF.net Dev2Dev email is sponsored by:
> 
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel

-- 
Frédéric Bouvier
http://my.fotolia.com/frfoto/  Photo gallery - album photo
http://www.youtube.com/user/fgfred64   Videos


--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT add airplane/scenery

[Michael Sgier]

Ok I did a fgdata clone:https://gitorious.org/~scrat/fg/scrats-fgdata

and pulled that ~3.5GB. Now I've added the aircrafts but push gives:
michael@ubuntu:/media/DATA/FGFS/install/fgfs/fgdata$ git push origin master
fatal: protocol error: expected sha/ref, got '
--
The git:// protocol is read-only.

Please use the push url as listed on the repository page.
--'
michael@ubuntu:/media/DATA/FGFS/install/fgfs/fgdata$ git push 
git://gitorious.org/~scrat/fg/scrats-fgdata.git
fatal: protocol error: expected sha/ref, got '
--
The git:// protocol is read-only.

Please use the push url as listed on the repository page.
--'


Thanks again. fgdata is still not splitted? It also seems to be incompatible 
to my fgfs git...maybe need to update that as well?


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git of fgdata today

[Torsten Dreyer]

Am 23.12.10 19:35, schrieb Donn Washburn:
> On 12/23/2010 12:24 PM, Gijs de Rooy wrote:
>>> FGDATA site seems to be down or have problems.  I have tried about 5
>>> times over time to get fgdata with the same error.
>> Gitorious was down since earlier today. However, it appears to be up
>> again now.
>>
>> You can still obtain fgdata from the mapserver clone though, if
>> Gitorious still doesn't
>> work: http://mapserver.flightgear.org/git/?p=fgdata;a=summary
>>
>> Cheers,
>> Gijs
> Thanks that seems to be working. It even seems faster
>
I saw many reports that mapserver is a faster than gitorious. Thanks, 
Martin!

Torsten (also bmw biker ;-)

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

[Flightgear-devel] No liveries

[Guy Brand]

Hi all,


I have a long standing issue with my installation of FlightGear. Here is
how it's set up:

  * git cloned sources under /home (i.e. /home/{simgear,flightgear,fgdata})
  * compilation of simgear and flightgear from the sources
cd /home/{simgear,flightgear}
git pull
./autogen.sh
./configure --prefix=/usr
make install
  * data refreshed from git and terrasync
cd /home/fgdata
git pull
terrasync -v -S -d /home/terrasync

The box is running ArchLinux. Now when I start fgfs

  FG_ROOT=/home/fgdata/ fgfs --fg-scenery="$FG_ROOT/Scenery/:/home/terrasync"

and select the "Select Livery" item from the menu, the list is always
empty, no livery is available, whatever plane I choose. I've tried
softlinking /home/fgdata to /usr/share/FlightGear/data, avoiding FG_ROOT
variable, moving fgdata to /home/fgdata/data, nothing helps.

Probably related side effect: if I choose the ufo aircraft, the "Select
Model" panel opened by hitting the space key, only shows two items
(marker.ac and sign.ac) from the UFO model, nothing else is listed.

Is my installation wrong? Any idea where the problem could come from?
Thanks in advance

-- 
bug


--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] use-custom-scenery-data

[Durk Talsma]

Hi Alex,

On 09 Jun 2011, at 11:21, Alex B. wrote:

> 
> No. 1)
> Durk wrote[1]: "[...]and the files that are still called "parking" are
> the ones that I still need to rename / improve / verify." There are
> still files called "parking" in the base package. Maybe someone will
> rename / improve / verify them before the 2.4.0 release. I even do
> volunteer for this job if I'd only know what to do and if there is no
> nasal or C++ coding involved.
> 
> find $fgdata/Scenery/ -name *parking*
> $fgdata/Scenery/Airports/K/H/W/KHWD.parking.xml
> $fgdata/Scenery/Airports/K/H/A/KHAF.parking.xml
> $fgdata/Scenery/Airports/K/O/A/KOAK.parking.xml
> $fgdata/Scenery/Airports/K/S/F/KSFO.parking.xml
> $fgdata/Scenery/Airports/K/S/J/KSJC.parking.xml
> 
> 
Basically, verifying the files would entail loading them into a recent version 
of taxidraw, selecting the "verify groundnetwork option" and correcting any 
errors indicated. Then they can be resaved. If you decide to do this, please 
ensure to send a copy to the updated files to me, so I can upload them to the 
terrasync repository. 

Cheers,
durk


--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] fgdata version in master branch

[Robert]

My fault. Sorry for the noise.


2012/2/5 Frederic Bouvier 

> Hi Robert,
>
> > De: "Robert"
>
> > Hi everybody,
>
> > since one or two weeks I have the following problem:
> > When I start fgfs it tells me that it needs version 2.7.0 of fgdata
> > and quits immediately.
> > I am using SimGear/Flightgear "next" branch, and fgdata "master"
> > branch.
> > After maually changing the version-file in fgdata from 2.5.0 to 2.7.0
> > everything is okay.
> > It would be nice if someone could change the version number to 2.7.0
> > in the "master" branch.
>
> Already done for awhile. See yourself :
> https://gitorious.org/fg/fgdata/blobs/master/version
>
> https://gitorious.org/fg/fgdata/commit/49283115c5042d42c68939b2942eeda7760df5fc
>
> Regards,
> -Fred
>
>
> --
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Bug 479 has come back

[Alan Teeder]

-Original Message- 
From: ThorstenB
Sent: Thursday, November 15, 2012 7:09 PM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Bug 479 has come back



Apparently the path checker somehow mismatches the given file path and
the fg-aircraft path. This is obviously caused by the conversion of the
path to an absolute path - but it's strange since absolute paths should
certainly work (and they are what should normally be given on the
command-line in the first place, so the conversion should not really
have changed anything, except for those who were using relative paths -
but those weren't even working before).

We either need someone running Windows to debug this.
Alternatively, please provide the exact values of the

* fg-aircraft command-line parameter ("--fg-aircraft=...")
* The value of the /sim/fg-aircraft property (see property tree)
* The exact path given in the error message "(loadxml: reading '...'
denied)"

Make sure to copy the paths exactly as shown - even tiny differences
(such as "/" vs "\", or an appended extra slash may make a difference).

cheers,
Thorsten


--
Thortsen

Here is my system.fgsrc file and then the log output.~

My TSR2, if you need it,  is at g...@gitorious.org:fg-ajt/tsr2.git.
The final Nasal error (nil used in numeric context) only occurs when I use 
the new version of simgear/misc/sg_path.cxx.

Changing --fg-aircraft=C:\FlightGear\MyAircraft 
to --fg-aircraft=C:\FlightGear\MyAircraft\ ,
or to   --fg-aircraft=C:/FlightGear/MyAircraft has no effect.

In each case the property /sim/fg-aircraft is that specified 
by --fg-aircraft=, except that the trailing " \" is discarded.

I ran flightgear with the command:
C:\FlightGear\install\msvc100\bin\fgfs.exe > fgfsrun.txt  2>&1

system.fgsrc:-
--fg-root=C:/FlightGear/fgdata
--fg-scenery=C:\FlightGear\MyScenery;C:\FlightGear\Terrasync;C:\FlightGear\flightgear
--fg-aircraft=C:\FlightGear\MyAircraft
--airport=EGNO
--aircraft=TSR2
--control=joystick
--enable-random-objects
--enable-horizon-effect
--enable-enhanced-lighting
--enable-ai-models
--enable-real-weather-fetch
--enable-clouds3d
--prop:/sim/frame-rate-throttle-hz=60
--prop:/sim/traffic-manager/enabled=0
--geometry=1024x768
--visibility-miles=30
--bpp=32
--log-level=alert
--timeofday=noon
--enable-rembrandt


Log file:
  No GAIN specified (default: 1.0)
loadxml: reading 'C:/FlightGear/MyAircraft/TSR2/Dialogs/config.xml' denied 
(unauthorized access)
Nasal runtime error: Dialog class: XML dialog must have 
  at C:/FlightGear/fgdata/Nasal/gui.nas, line 354
  called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 334
  called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100
Nasal runtime error: container index not scalar
  at C:/FlightGear/fgdata/Nasal/gui.nas, line 336
  called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-main.nas, line 26
Switches.nas
Annunciator.nas
controls.nas
timers.nas
electrical.nas
Engine-Start-Stop.nas
TSR2 undercarriage.nas
settimer(gearLights, 0);
navradiodisplay.nas
g-meter.nas
ice-warn.nas
Init properties.nas
startup.nas
dropview.nas
TSR2-moving-map.nas
TSR2 autopilot.nas
TSR2 contrail.nas
TSR2 liveries.nas
loadxml: reading 
'C:/FlightGear/MyAircraft/TSR2/Models/Liveries/BlackTest.xml' denied 
(unauthorized access)
Nasal runtime error: non-objects have no members
  at C:/FlightGear/fgdata/Nasal/gui.nas, line 479
  called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 460
  called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 450
  called from: C:/FlightGear/fgdata/Nasal/aircraft.nas, line 519
  called from: C:/FlightGear/MyAircraft/TSR2/Nasal/liveries.nas, line 4
dialogs.nas
loadxml: reading 
'C:/FlightGear/MyAircraft/TSR2/Dialogs/TSR2-autopilot-dlg.xml' denied 
(unauthorized access)
Nasal runtime error: Dialog class: XML dialog must have 
  at C:/FlightGear/fgdata/Nasal/gui.nas, line 354
  called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 334
  called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100
Nasal runtime error: container index not scalar
  at C:/FlightGear/fgdata/Nasal/gui.nas, line 336
  called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-dialogs.nas, line 7
TSR2 canvas HUD.nas
loading scenario 'nimitz_demo'
map init-props
moving map loaded
Nasal runtime error: nil used in numeric context
  at C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-canvas-HUD.nas, line 276
  called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-canvas-HUD.nas, line 
354
  called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100
Nasal runtime error: nil used in numeric context
  at C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-g-meter.nas, line 14
icewarn

I hope that this helps debug the problem.

Alan


--
Monitor your physical, virtual an

Re: [Flightgear-devel] Building FlightGear under Vista

[Anders Gidenstam]

On Sat, 4 Sep 2010, Jon S. Berndt wrote:

> Which directory should one be under when they execute the git command?

Hi,

You should be in the directory where you want to have the fgdata 
directory, i.e. git creates fgdata in the current directory.
Cloning will download about 2.5GB of data so it will take a good while.
If gitorious is slow you can also clone from
http://mapserver.flightgear.org/git/fgdata

> Is there anything that needs to be done afterwards when the data is all 
> downloaded, or is FlightGear ready to run at that point?

FlightGear should be ready to run at that point. Use the 
--fg-root=/path/to/fgdata
argument to point FlightGear to the fgdata directory - it probably won't 
find it otherwise.

Cheers,

Anders
-- 
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git of fgdata today

[Donn Washburn]

On 12/23/2010 12:24 PM, Gijs de Rooy wrote:
> > FGDATA site seems to be down or have problems.  I have tried about 5
> > times over time to get fgdata with the same error.
>
> Gitorious was down since earlier today. However, it appears to be up 
> again now.
>
> You can still obtain fgdata from the mapserver clone though, if 
> Gitorious still doesn't
> work: http://mapserver.flightgear.org/git/?p=fgdata;a=summary
>
> Cheers,
> Gijs
Thanks that seems to be working. It even seems faster

-- 
73 de Donn Washburn
307 Savoy Street Email:" n5...@comcast.net "
Sugar Land, TX 77478 LL# 1.281.242.3256
Ham Callsign N5XWB   HAMs : " n5...@arrl.net "
VoIP via Gizmo: bmw_87kbike / via Skype: n5xwbg
BMW MOA #: 4146 - Ambassador
   " http://counter.li.org " #279316


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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after

[Jari Häkkinen]

I actually lost track of who is doing what in the splitting of fgdata 
but there is a tremendous response pointing out issues related to the 
split. I want to express support for the splitting team.

I support the split if only for the reason that aircraft maintainers 
will get commit rights to their private spheres in fg-land (if I 
understand things properly). With the previous monolithic fgdata only a 
selected group of people had commit privileges.

Once the dust settles I think we will see the benefits of giving 
aircraft developers direct access to "their" repos. At least the need 
for setting up other repos will decrease (assuming that not all aircraft 
developers are anti-GPL) because I think one major reason for setting up 
external repos are (lack of) commit privileges in fgdata.


For those of you who are impatient with the progress, is the now frozen 
fgdata unusable? Why not stay with it until the new fgdata is to your 
liking? I haven't pulled the latest fg-state lately so I don't know if 
this is possible to stay old-school?


Cheers,

Jari

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Ciosco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Joystick Dialog - Windows

[Alan Teeder]

I see this when I open the Joystick dialogue.:-
Nasal runtime error: non-objects have no members
  at C:/FlightGear/fgdata/Nasal/joystick.nas, line 532
  called from: __dlg:joystick-config, line 9

This when I press “Reset Configuration”:-
Nasal runtime error: bad/missing argument to split()
  at C:/FlightGear/fgdata/Nasal/string.nas, line 235
  called from: C:/FlightGear/fgdata/Nasal/joystick.nas, line 693
  called from: C:/FlightGear/fgdata/Nasal/joystick.nas, line 702
  called from: /sim/bindings/gui/binding[9], line 2

And this when I press “Refresh Joysticks”
Nasal runtime error: non-objects have no members
  at C:/FlightGear/fgdata/Nasal/joystick.nas, line 532
  called from: __dlg:joystick-config, line 9

“Joystick (name)” is shown as blank., but the Aileron, Elevator, Rudder and 
Throttle values are all updated in the dialogue when I move the joystick. The 
buttons are not displayed in the dialogue.

In the property tree I have the   ‘Lifeteck Skymaster joystick’  in 
/input/joysticks/js

There is no property “id” in the joystick property tree, but all the axes and 
buttons properties are shown and active.
fgdata/joysticks.xml is as follows:-
 
  
 


Is this a windows problem, or something else?--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] fgdata is frozen!

[ThorstenB]

Jorg and Gijs are working on the new fgdata repo now.
Therefore the existing fgdata repo is frozen as of now - even commit 
privileges are removed - hopefully permanently for the (historic) fgdata 
repo.

They'll start a new (temporary) repository. Once the new repo is all 
setup and working as expected, we'll switch (shuffle the names) and add 
committers.

cheers,
Thorsten

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Bug 479 has come back

[Vivian Meazza]

Alan wrote:

 -Original Message-
> From: ThorstenB
> Sent: Thursday, November 15, 2012 7:09 PM
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Bug 479 has come back
> 
> 
> 
> Apparently the path checker somehow mismatches the given file path and
> the fg-aircraft path. This is obviously caused by the conversion of the
> path to an absolute path - but it's strange since absolute paths should
> certainly work (and they are what should normally be given on the
> command-line in the first place, so the conversion should not really
> have changed anything, except for those who were using relative paths -
> but those weren't even working before).
> 
> We either need someone running Windows to debug this.
> Alternatively, please provide the exact values of the
> 
> * fg-aircraft command-line parameter ("--fg-aircraft=...")
> * The value of the /sim/fg-aircraft property (see property tree)
> * The exact path given in the error message "(loadxml: reading '...'
> denied)"
> 
> Make sure to copy the paths exactly as shown - even tiny differences
> (such as "/" vs "\", or an appended extra slash may make a difference).
> 
> cheers,
> Thorsten
> 
> 
>

--
> Thortsen
> 
> Here is my system.fgsrc file and then the log output.~
> 
> My TSR2, if you need it,  is at g...@gitorious.org:fg-ajt/tsr2.git.
> The final Nasal error (nil used in numeric context) only occurs when I use
> the new version of simgear/misc/sg_path.cxx.
> 
> Changing --fg-aircraft=C:\FlightGear\MyAircraft
> to --fg-aircraft=C:\FlightGear\MyAircraft\ ,
> or to   --fg-aircraft=C:/FlightGear/MyAircraft has no effect.
> 
> In each case the property /sim/fg-aircraft is that specified
> by --fg-aircraft=, except that the trailing " \" is discarded.
> 
> I ran flightgear with the command:
> C:\FlightGear\install\msvc100\bin\fgfs.exe > fgfsrun.txt  2>&1
> 
> system.fgsrc:-
> --fg-root=C:/FlightGear/fgdata
> --fg-
> scenery=C:\FlightGear\MyScenery;C:\FlightGear\Terrasync;C:\FlightGear\fli
> ghtgear
> --fg-aircraft=C:\FlightGear\MyAircraft
> --airport=EGNO
> --aircraft=TSR2
> --control=joystick
> --enable-random-objects
> --enable-horizon-effect
> --enable-enhanced-lighting
> --enable-ai-models
> --enable-real-weather-fetch
> --enable-clouds3d
> --prop:/sim/frame-rate-throttle-hz=60
> --prop:/sim/traffic-manager/enabled=0
> --geometry=1024x768
> --visibility-miles=30
> --bpp=32
> --log-level=alert
> --timeofday=noon
> --enable-rembrandt
> 
> 
> Log file:
>   No GAIN specified (default: 1.0)
> loadxml: reading 'C:/FlightGear/MyAircraft/TSR2/Dialogs/config.xml' denied
> (unauthorized access)
> Nasal runtime error: Dialog class: XML dialog must have 
>   at C:/FlightGear/fgdata/Nasal/gui.nas, line 354
>   called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 334
>   called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100
> Nasal runtime error: container index not scalar
>   at C:/FlightGear/fgdata/Nasal/gui.nas, line 336
>   called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-main.nas, line 26
> Switches.nas
> Annunciator.nas
> controls.nas
> timers.nas
> electrical.nas
> Engine-Start-Stop.nas
> TSR2 undercarriage.nas
> settimer(gearLights, 0);
> navradiodisplay.nas
> g-meter.nas
> ice-warn.nas
> Init properties.nas
> startup.nas
> dropview.nas
> TSR2-moving-map.nas
> TSR2 autopilot.nas
> TSR2 contrail.nas
> TSR2 liveries.nas
> loadxml: reading
> 'C:/FlightGear/MyAircraft/TSR2/Models/Liveries/BlackTest.xml' denied
> (unauthorized access)
> Nasal runtime error: non-objects have no members
>   at C:/FlightGear/fgdata/Nasal/gui.nas, line 479
>   called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 460
>   called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 450
>   called from: C:/FlightGear/fgdata/Nasal/aircraft.nas, line 519
>   called from: C:/FlightGear/MyAircraft/TSR2/Nasal/liveries.nas, line 4
> dialogs.nas
> loadxml: reading
> 'C:/FlightGear/MyAircraft/TSR2/Dialogs/TSR2-autopilot-dlg.xml' denied
> (unauthorized access)
> Nasal runtime error: Dialog class: XML dialog must have 
>   at C:/FlightGear/fgdata/Nasal/gui.nas, line 354
>   called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 334
>   called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100
> Nasal runtime error: container index not scalar
>   at C:/FlightGear/fgdata/Nasal/gui.nas, line 336
>   called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-dialogs.nas, line
7
> TSR2 canvas HUD.nas
> loadin

[Flightgear-devel] [SPAM] Re: Proposal: Move airplanes to an SVN repository

[Emilian Huminiuc]

On Friday 12 August 2011 14:02:16 Tim Moore wrote:
> I've started the first phase of trimming down fgdata. I've removed the
> an2 from fgdata and put it in its own repository called "ac-an2" under
> the Flightgear project. I'm going to proceed with moving other
> aircraft which haven't been touched in a while into their own repos as
> well. When we get down to a working set of aircraft that are currently
> under development, I will turn off commit rights in fgdata for a short
> period while I extract those aircraft. I will then regenerate fgdata
> without the history of all the aircraft, which will shrink the fgdata
> repository a great deal.
> 
> I've started putting "ac-" in front of the aircraft repository names
> in order to aid tools that manage aircraft downloads, etc.
> 
> Aircraft developers: please don't add new aircraft to fgdata! You can
> easily set up your own repositories on gitorious and later request
> that we "incorporate" a repository into the Flightgear project.
> 
> Tim
> 

Hi, let's say I would like the Lockheed L10 Electra included, how would I go 
about doing that (or is it too early to think about this ? )
Repo is currently here https://gitorious.org/lockheed-l10-electra



--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. 
http://p.sf.net/sfu/wandisco-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] FGData New Structure

[Cedric Sodhi]

Dear Everyone,

I hope this is the last time we will have to discuss this topic, since
over the last months it seemed that everyone agreed with that FGDATA

- has to be split sometime
- should be split a.s.a.p.

We agreed that after the current release of 2.4 would be a good point to
get the project on the way. As I offered and it still stands, I will
take care of writing the bash script which "splits" the current FGDATA
repository into multiple repositories and leaves an FGDATA repository
which holds merely the bare essentials which supplement the core binary
of fgfs. One could classify the contents of the new FGDATA by saying
that it's data which provides the technical backbone - the common
denominator everything is based upon.

I'd like to cease this opportunity to give everyone the chance to utter
their possible disagreement with the project or their respective
opinions and discuss the very details of the split, which have not yet
been determined.

The general boundary conditions of the splitting process are the following:

- FGDATA shall consist of everything which is essential for the binary
  to run and shall not hold any data which is specific to certain
  airports or airplanes. Those should be provided in separate
  repositories the structure of which is not of current interest and
  might possibly be chosen by the respective authors.

- The change shall not require restructuring of the architecture,
  including the directory structure. Solely the repositories in which
  the data is contained shall change.

Informatively, I'd like to supply a sensible suggestion for how a final
structure might look and how, either as a developer or user might use
it. Particularily, because some of you might wonder how we can strip
FGDATA of KSFO and the 172p, leaving nothing to fly with - isn't that a
bad decision?

Definitly not. One has to distinguish between a proper, dedicated
development structure which is aligned to and substructred into
independent development units and a way of deployment.

As a developer, you will clone the base fgfs SC repository and you will
clone the FGDATA repository. Then, depending on your field of interest
you will clone the aircrafts, airports etc. you are planning to work on.

You can do so with the git submodule, which will integrate the specific
aircraft/airport/etc repository into the existing FGDATA repository,
while keeping the commits separate.

For deployment, you either manually or programatically git-submodule all
data required for shipping into a branch for deployment. This includes,
for instance, the KSFO tile and the c172p. It's apparent that one, among
many advantages of that approach is, that the confusing redundancy
between the "default KSFO" and the "scenery KSFO", as it currently
exists, will go.

While the planes are the primary concern of the splitting and will bring
a relief of a tremendous 4.5 Gigabytes to every user of FGDATA and
rectify a lot of redundancies and confusion, other things might also be
considered, say, ./Traffic (just a lucky guess).

Practically everything which is orthogonal to the core and without which
FG (assuming a plane and a tile) can properly run, should migrate.

regards,
ManDay

--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Flightgear-devel Digest, Vol 80, Issue 8

[Clement de l'Hamaide]

> I have had no contact with them either by 
phone or otherwise.

http://equipe-flightgear.forumactif.com/t899p30-pour-une-meilleur-integration-des-travaux-de-la-paf-dans-flightgear#15971
In English the last line is << let me know when you're ready and I call him >>

 
http://equipe-flightgear.forumactif.com/t899p45-pour-une-meilleur-integration-des-travaux-de-la-paf-dans-flightgear#16025
 
In English the second line is << I've just talked during a long time with 
Emmanuel (more than one hour !!!) >>



> leaves IRC very quickly when I arrive

??? hmmm someone can explain me ? Emilian ? James ? Christian ? Gijs ? Jean ? 
David ? Anders ?  Have I left IRC because helijah was connected on IRC ?



> I never removed the header indicating the authors

Some example :
Original file created by PAF team : 
https://gitorious.org/paf/fgdata/blobs/master/Aircraft/DR400-jsbSim/Dialogs/checklist/checklists-text.xml
File currently on GIT repo : 
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/DR400/Dialogs/checklist/checklists-text.xml;h=a60d0954b08d8a7e71a802c191e71c96a15f55e6;hb=HEAD

Original file created by PAF team : 
https://gitorious.org/paf/fgdata/blobs/master/Aircraft/DR400-jsbSim/Models/Interior/Handle/handle.xml
File currently on GIT repo : 
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/DR400/Models/Interior/Handle/handle.xml;h=d9aa7be75d5a201ab32e384d4ab7c7587150cabf;hb=HEAD

Original file created by PAF team : 
https://gitorious.org/paf/fgdata/blobs/master/Aircraft/DR400-jsbSim/Models/Interior/Panel/Parts/fuel-valve/fuel-valve.xml
File currently on GIT repo : 
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/DR400/Models/Interior/Panel/Parts/fuel-valve/fuel-valve.xml;h=d162e7bef1bda983df51f7949afbc3e244b129cc;hb=HEAD

Original file created by PAF team : 
https://gitorious.org/paf/fgdata/blobs/master/Aircraft/DR400-jsbSim/Nasal/dr400.nas
File
 currently on GIT repo : 
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/DR400/Nasal/dr400.nas;h=c27fa190acac2ecbda8de3539a81fd57c0e30063;hb=HEAD

Original file created by PAF team : 
https://gitorious.org/paf/fgdata/blobs/master/Aircraft/DR400-jsbSim/Nasal/electrical.nas
File currently on GIT repo : 
http://mapserver.flightgear.org/git/?p=fgdata;a=blob;f=Aircraft/DR400/Nasal/electrical.nas;h=195a5ad1a6a31076ca8a0c66563a8b4687de6a30;hb=HEAD

Should I continue ?

In the 3 first examples this is missing :


In the 2 last examples the header copyright has been changed : the destinated 
project of my contribution is now "DR400" and the forum URL of PAF team is 
removed from dr400.nas / replaced by my personal website URL ( ??? ) from 
electrical.nas 
Firstly my contribution was originaly written for the DR400-jsbSim project 
(Imagine that profightsim change the header of the file from "This file is part 
of FlightGear" by "This file is part of proflightsim"... here is exactly the 
same)
Secondly I don't understand why my personal website URL is in these files ! My 
personal life has nothing to do with these file. I use my website for personal 
and professional use and I've never wanted to see this URL in these files. 

Currently the GIT repo is not "GPL compliant" at all...
Now I leave you conclude and make what is necessary in order to stop all of 
these. 


Cheers,
Clément
  --
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT and FGDATA

[Alan Teeder]

--
From: "Alasdair" 
Sent: Saturday, August 07, 2010 10:47 AM
To: "FlightGear developers discussions" 

Cc: 
Subject: Re: [Flightgear-devel] GIT and FGDATA

> On Fri, 2010-08-06 at 07:59 -0600, dave perry wrote:
>> I am not seeing the slowdown.  I just ran a simple script that updates
>> simgear, flightgear source, and fgdata.  I would estimate that the "git
>> pull origin" run in fgdata took about 3 minutes.  This performance has
>> been typical for me.  I  ran System Monitor (F12) during the fgdata pull
>> and the data rate was between 96 and 100 KB/s and the memory usage was
>> constant.  I connect via Earthlink dsl.
>>
>> Dave P.
>
> I experience much the same as Dave. A git pull in fgdata is no big
> deal.Here is the output from a little test i just ran :
>
> pull started Sat Aug 7 10:32:03 BST 2010
> ===
> New directory is /opt/FlightGear/fgdata
>>From git://gitorious.org/fg/fgdata
>   33b8fe6..74ec1cd  master -> origin/master
> Updating 33b8fe6..74ec1cd
> Fast-forward
> Aircraft/737-300/Models/contrail.xml   |  216 +-
> Aircraft/C130/Models/main.xml  |   33 +
> Aircraft/Concorde/Concorde-set.xml |8 +-
> Aircraft/Concorde/Models/Concorde_ba.xml   |   21 +
> Aircraft/Concorde/Models/Effects/contrail-new.xml  |  142 +
> Aircraft/Concorde/Models/Effects/contrail1.eff |  156 +
> Aircraft/Concorde/Models/Effects/contrail2.eff |  151 +
> .../Concorde/Models/Effects/contrail_dummy.xml |   11 +
> .../Concorde/Models/Effects/contrail_shader1.xml   |   35 +
> .../Concorde/Models/Effects/contrail_shader2.xml   |   35 +
> Aircraft/Concorde/Models/Effects/smoke.png |  Bin 0 -> 6482
> bytes
> Aircraft/Concorde/concorde-submodels.xml   |   28 +
> Aircraft/Concorde/concorde-subsubmodels.xml|   66 +
> Aircraft/Concorde/concorde-subsubsubmodels.xml |   67 +
> Aircraft/Concorde/concorde-subsubsubsubmodels.xml  |   64 +
> Aircraft/Short_Empire/Models/Interior/interior.ac  | 8138
> +---
> Aircraft/Short_Empire/Models/Interior/interior.xml |  312 +-
> .../Short_Empire/Models/Interior/spar_panel.xml|   10 +-
> Aircraft/Short_Empire/Short_Empire-set.xml |   25 +-
> Aircraft/Short_Empire/Short_S23.xml|   59 +-
> Aircraft/Short_Empire/Systems/fuel-system.xml  |   20 +-
> Aircraft/Short_Empire/Systems/short-empire.nas |   11 +-
> 22 files changed, 8171 insertions(+), 1437 deletions(-)
> create mode 100644 Aircraft/Concorde/Models/Effects/contrail-new.xml
> create mode 100644 Aircraft/Concorde/Models/Effects/contrail1.eff
> create mode 100644 Aircraft/Concorde/Models/Effects/contrail2.eff
> create mode 100644 Aircraft/Concorde/Models/Effects/contrail_dummy.xml
> create mode 100644
> Aircraft/Concorde/Models/Effects/contrail_shader1.xml
> create mode 100644
> Aircraft/Concorde/Models/Effects/contrail_shader2.xml
> create mode 100644 Aircraft/Concorde/Models/Effects/smoke.png
> create mode 100644 Aircraft/Concorde/concorde-submodels.xml
> create mode 100644 Aircraft/Concorde/concorde-subsubmodels.xml
> create mode 100644 Aircraft/Concorde/concorde-subsubsubmodels.xml
> create mode 100644 Aircraft/Concorde/concorde-subsubsubsubmodels.xml
> ===
> pull ended Sat Aug 7 10:32:40 BST 2010
> fgdata git pull took 0 mins 37 seconds
>
> ===
> My connection is BT Broadband, nominally 12 Mbps, but actually 7,616
> Kbps.
> My machine is based on a 2x AMD Athlon(tm) 7450 Dual-Core Processor
> with 2 GB mem.
>
> Kind regards,
> Aasdair
>
>

I have just done a very quick and successful fgdata git pull using Cygwin. 
The results were similar to Alistair´s above.

Cygwin git also threw up some errors in my Simgear directory that Totoise 
git (even using the "Diff" and "Check for Modifications" options had not 
found.)

>From now on I will keep away from Tortoise git.

Alan

 


--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT and FGDATA

[Vivian Meazza]

Alan Teeder wrote

> 
> --
> From: "Alasdair" 
> Sent: Saturday, August 07, 2010 10:47 AM
> To: "FlightGear developers discussions"
> 
> Cc: 
> Subject: Re: [Flightgear-devel] GIT and FGDATA
> 
> > On Fri, 2010-08-06 at 07:59 -0600, dave perry wrote:
> >> I am not seeing the slowdown.  I just ran a simple script that updates
> >> simgear, flightgear source, and fgdata.  I would estimate that the "git
> >> pull origin" run in fgdata took about 3 minutes.  This performance has
> >> been typical for me.  I  ran System Monitor (F12) during the fgdata
> pull
> >> and the data rate was between 96 and 100 KB/s and the memory usage was
> >> constant.  I connect via Earthlink dsl.
> >>
> >> Dave P.
> >
> > I experience much the same as Dave. A git pull in fgdata is no big
> > deal.Here is the output from a little test i just ran :
> >
> > pull started Sat Aug 7 10:32:03 BST 2010
> > ===
> > New directory is /opt/FlightGear/fgdata
> >>From git://gitorious.org/fg/fgdata
> >   33b8fe6..74ec1cd  master -> origin/master
> > Updating 33b8fe6..74ec1cd
> > Fast-forward
> > Aircraft/737-300/Models/contrail.xml   |  216 +-
> > Aircraft/C130/Models/main.xml  |   33 +
> > Aircraft/Concorde/Concorde-set.xml |8 +-
> > Aircraft/Concorde/Models/Concorde_ba.xml   |   21 +
> > Aircraft/Concorde/Models/Effects/contrail-new.xml  |  142 +
> > Aircraft/Concorde/Models/Effects/contrail1.eff |  156 +
> > Aircraft/Concorde/Models/Effects/contrail2.eff |  151 +
> > .../Concorde/Models/Effects/contrail_dummy.xml |   11 +
> > .../Concorde/Models/Effects/contrail_shader1.xml   |   35 +
> > .../Concorde/Models/Effects/contrail_shader2.xml   |   35 +
> > Aircraft/Concorde/Models/Effects/smoke.png |  Bin 0 -> 6482
> > bytes
> > Aircraft/Concorde/concorde-submodels.xml   |   28 +
> > Aircraft/Concorde/concorde-subsubmodels.xml|   66 +
> > Aircraft/Concorde/concorde-subsubsubmodels.xml |   67 +
> > Aircraft/Concorde/concorde-subsubsubsubmodels.xml  |   64 +
> > Aircraft/Short_Empire/Models/Interior/interior.ac  | 8138
> > +---
> > Aircraft/Short_Empire/Models/Interior/interior.xml |  312 +-
> > .../Short_Empire/Models/Interior/spar_panel.xml|   10 +-
> > Aircraft/Short_Empire/Short_Empire-set.xml |   25 +-
> > Aircraft/Short_Empire/Short_S23.xml|   59 +-
> > Aircraft/Short_Empire/Systems/fuel-system.xml  |   20 +-
> > Aircraft/Short_Empire/Systems/short-empire.nas |   11 +-
> > 22 files changed, 8171 insertions(+), 1437 deletions(-)
> > create mode 100644 Aircraft/Concorde/Models/Effects/contrail-new.xml
> > create mode 100644 Aircraft/Concorde/Models/Effects/contrail1.eff
> > create mode 100644 Aircraft/Concorde/Models/Effects/contrail2.eff
> > create mode 100644 Aircraft/Concorde/Models/Effects/contrail_dummy.xml
> > create mode 100644
> > Aircraft/Concorde/Models/Effects/contrail_shader1.xml
> > create mode 100644
> > Aircraft/Concorde/Models/Effects/contrail_shader2.xml
> > create mode 100644 Aircraft/Concorde/Models/Effects/smoke.png
> > create mode 100644 Aircraft/Concorde/concorde-submodels.xml
> > create mode 100644 Aircraft/Concorde/concorde-subsubmodels.xml
> > create mode 100644 Aircraft/Concorde/concorde-subsubsubmodels.xml
> > create mode 100644 Aircraft/Concorde/concorde-subsubsubsubmodels.xml
> > ===
> > pull ended Sat Aug 7 10:32:40 BST 2010
> > fgdata git pull took 0 mins 37 seconds
> >
> > ===
> > My connection is BT Broadband, nominally 12 Mbps, but actually 7,616
> > Kbps.
> > My machine is based on a 2x AMD Athlon(tm) 7450 Dual-Core Processor
> > with 2 GB mem.
> >
> > Kind regards,
> > Aasdair
> >
> >
> 
> I have just done a very quick and successful fgdata git pull using Cygwin.
> The results were similar to Alistair´s above.
> 
> Cygwin git also threw up some errors in my Simgear directory that Totoise
> git (even using the "Diff" and "Check for Modifications" options had not
> found.)
> 
> >From now on I will keep away from Tortoise git.
> 

MySys git-bash shell works as well - and saves the complications of cygwin.
Mind you - I'm beginning to work up a method which uses the bits of
tortoise-git that do work and use git-bash for those that don't.



--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] request for FGDATA commit please.

[Scott]

 thanks Gijs, it looks like all the other changes from the source
tarball didn't come through? 

 there should a very large number of deletes
and modifies... 

 cheers 

 S. 

On Wed, 15 Dec 2010 22:34:19 +0100, Gijs
de Rooy  wrote:  > So could someone with commit rights to fgdata please
replace the A380 aircraft by;

Done:
http://gitorious.org/fg/fgdata/commit/05721b5fb2d374adf80ec6cf4e05ba4e66012e8a
[1]
Please check if all went well. 

Cheers,
Gijs  

 

Links:
--
[1]
http://gitorious.org/fg/fgdata/commit/05721b5fb2d374adf80ec6cf4e05ba4e66012e8a
--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] File sizes in fgdata, clean up needed?

[ThorstenB]

On 18.03.2011 17:50, HB-GRAL wrote:
> Today I checked the current fgdata/Aircraft folder for sizes. It’s about
> 4,3 GB here. Nice.
>
> Some of this files are .gz already, when I .gz the rest I get another
> 100 MB, or in other words I get two MiG-15 or another p51d.

Nice statistics! Maybe this motivates some of us to be a bit more 
considerate before committing something to the repo.

However, remember that dropping any file from the repository wouldn't 
help at all now: a git repository never shrinks - it can only grow... 
It's an especially bad idea to drop files and resubmit a 
smaller/compressed version in a futile attempt to shrink the repository.
git contains a complete history of every file. If you dropped files and 
resubmitted a smaller version, the local fgdata directories may at first 
appear smaller - but if you checked the total size (that is including 
the hidden ".git" folders) you'll see that the total size was actually 
increased...

And another warning: the complete history issue also affects personal 
git branches on gitorious. So, if an a/c designer adds 19 versions of an 
image file to his private branch and then placed a "merge request" to 
fgdata/master - then the merge will actually copy the history of all 19 
file versions to the master branch - even the history of files which 
were already dropped on the private branch. So, in such cases it's a 
good idea to not actually "git merge" the complete personal branch to 
our "master" - but to simply take a copy of the latest version of the 
a/c files and to submit them to "master" using a fresh commit (I think 
that's what our fgdata-merge-committers do anyway - at least I hope 
so...). Or maybe any git expert knew if there was a 
git-merge-without-history command?

Indeed, fgdata/master is becoming way too big though. But we can only 
solve this by splitting our current repository - and then push the 
different parts to fresh git repositories. Splitting fgdata was planned 
anyway. The new "--fg-aircraft" options was the first step to make this 
possible. I'm just not sure what the status of splitting fgdata is though...

cheers,
Thorsten


--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Building FlightGear under Vista

[Alan Teeder]

--
From: "Jon S. Berndt" 
Sent: Sunday, September 05, 2010 1:27 PM
To: "'FlightGear developers discussions'" 

Subject: Re: [Flightgear-devel] Building FlightGear under Vista

>> That helped, but now I am getting different errors:
>>
>> --- start ---
>> $ FlightGear/projects/VC90/Win32/Release/fgfs --fg-
>> root=c:/cygwin/home/jon/flightgear/fgdata/
>> Processing command line arguments
>> using aircraft-dir
>> for:c:/cygwin/home/jon/flightgear/fgdata//Aircraft/c172p/splash.png
>> Warning: Could not find plugin to read objects from file
>> "c:/cygwin/home/jon/flightgear/fgdata//Aircraft/c172p/splash.png".
>> Warning: Could not find plugin to read objects from file
>> "c:/cygwin/home/jon/flightgear/fgdata//Fonts/Helvetica.txf".
>> Warning: Could not find plugin to read objects from file
>> "c:/cygwin/home/jon/flightgear/fgdata//Fonts/Helvetica.txf".
>> Warning: Could not find plugin to read objects from file
>> "c:/cygwin/home/jon/flightgear/fgdata//Fonts/Helvetica.txf".
>> using aircraft-dir
>> for:c:/cygwin/home/jon/flightgear/fgdata//Aircraft/c172p/c172-sound.xml
>> using aircraft-dir
>> for:c:/cygwin/home/jon/flightgear/fgdata//Aircraft/c172p/Models/c172p.x
>> ml
>> Failed to load model: Failed to load 3D model:
>> from:Aircraft/c172p/Models/c172p.xml
>> ...
>> --- end ---
>>
>> Yet all of the plugins are clearly accessible. For example,
>>
>> which osg2cpp
>>
>> Yields:
>>
>> /home/jon/flightgear/install/msvc90/OpenSceneGraph/bin/osg2cpp
>>
>> The cygwin bash command line recognizes the path, but it seems that
>> FlightGear may not recognize the path. How does this work in Linux?
>>
>> Jon

Why are you using cygwin for this?

FG builds well with XP and Vista in the Windows environment with Visual 
Studio Express 2008.  See the instructions on the wiki  at 
http://wiki.flightgear.org/index.php/Building_FlightGear_-_Windows which 
will give you a good start point.

The biggest problem is with the 3rd party stuff, each of which (especially 
OpenSceneGraph) has its own 3rd party requirements. This is only relevant 
if you really MUST build your own to to date version of each and not rely on 
the distributions suggested in the Wiki.  Also the 3rd part  stuff keeps 
changing, so it is very difficult to be at the cutting edge.

A Visual Studio 2010 build with fully up to date 3rd part stuff is 
possible - I have done it here, but at the moment it is not worth the 
hassle. 


--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT and FGDATA

[Alan Teeder]

--
From: "dave perry" 
Sent: Friday, August 06, 2010 2:59 PM
To: ; "FlightGear developers discussions" 

Subject: Re: [Flightgear-devel] GIT and FGDATA

> I am not seeing the slowdown.  I just ran a simple script that updates
> simgear, flightgear source, and fgdata.  I would estimate that the "git
> pull origin" run in fgdata took about 3 minutes.  This performance has
> been typical for me.  I  ran System Monitor (F12) during the fgdata pull
> and the data rate was between 96 and 100 KB/s and the memory usage was
> constant.  I connect via Earthlink dsl.
>
> Dave P.

Dave

>From earlier posts I surmise that you have a 64bit Linux box.
I have an old single processor XP box (limited to 1 GB memory by the 
motherboard) and a newer dual-core laptop. These run Xp and Vista 
respectively. Not in the same league as yours :-(


My searching on the net suggests that the Windows version of Git is not as 
fast as the Linux original. The net result is that Git on Windows needs a 
higher spec processor than flightgear does when used with a large and 
frequently changing set of data such as fgdata.

During "pull origin" Git´s CPU usage goes to 100% (or 50% on the dual core 
box)  and Gits´s memory increases to over 100M, but there is negligible net 
usage.  I have let it run for 3 hours with no sign of any completion. My 
guess is that Windows Git is having trouble sorting out all the changes and 
updating its internal databases.

Alan 


--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] fgdata version in master branch

[Robert]

Hi everybody,

since one or two weeks I have the following problem:
When I start fgfs it tells me that it needs version 2.7.0 of fgdata and
quits immediately.
I am using SimGear/Flightgear "next" branch, and fgdata "master" branch.
After maually changing the version-file in fgdata from 2.5.0 to 2.7.0
everything is okay.
It would be nice if someone could change the version number to 2.7.0 in the
"master" branch.

cheers,
Robert
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Torsten Dreyer]

Am 18.10.2011 19:30, schrieb Gijs de Rooy:
>  > Torsten wrote:
>  > For some reason, there seems to be no ssh url available for fgdata-new
>  > and the aircraft projects?
>
> There is. g...@gitorious.org:fg/fgdata-new.git
> <mailto:g...@gitorious.org:fg/fgdata-new.git> and for the aircraft it's like
> g...@gitorious.org:flightgear-aircraft/c172p.git
> <mailto:g...@gitorious.org:flightgear-aircraft/c172p.git> (all aircraft
> repos simply match
> the respective aircraft's directory name).
>
> You mean you don't see it at Gitorious? Works fine here on IE9 and FF7...
Sorry, I was referring to the clone/push url. Surely the gitorious web 
site works as expected.

The ssh url is required (iirc) to access gitorious with the public key 
as a commiter.

git clone g...@gitorious.org:fg/fgdata-new data

fails with

Cloning into data...

== Gitorious: ==
Access denied or bad command


fatal: The remote end hung up unexpectedly

before I can enter my private key.

Torsten

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git

[ThorstenB]

On 28.09.2011 14:57, Michael Sgier wrote:
> Am I doing something wrong or do I need permissions etc.?

Did you create an account on gitorious.org and add your SSH key? Next 
step then is to create a personal fgdata clone with your gitorious 
account. The idea is to push your personal changes to your own clone, 
and then place a merge request to fg/fgdata. You can't push updates 
directly to fg/fgdata (at least not unless you've been using and got 
accustomed to git + gitorious for a while - and are a regular fgdata 
contributor).

cheers,
Thorsten

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] fgdata trouble

[Alan Teeder]

-Original Message- 
From: Martin Spott
Sent: Sunday, September 23, 2012 11:42 AM Newsgroups: list.flightgear-devel
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] fgdata trouble

"Alan Teeder" wrote:

> Twice I left it running overnight, but it failed both times after several
> hours during the fgdata clone.

Which server do you clone from ?  If you don't already do so, then you
should consider fetching the initial clone from mapserver and to change
the remote origin afterwards.

---

Martin

Brisa script has this line
git clone git://gitorious.org/fg/fgdata.git fgdata

This is also the default to which all new users are most likely to come 
across..

Alan 


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT and FGDATA

[Alasdair]

On Fri, 2010-08-06 at 07:59 -0600, dave perry wrote: 
> I am not seeing the slowdown.  I just ran a simple script that updates 
> simgear, flightgear source, and fgdata.  I would estimate that the "git 
> pull origin" run in fgdata took about 3 minutes.  This performance has 
> been typical for me.  I  ran System Monitor (F12) during the fgdata pull 
> and the data rate was between 96 and 100 KB/s and the memory usage was 
> constant.  I connect via Earthlink dsl.
> 
> Dave P.

I experience much the same as Dave. A git pull in fgdata is no big
deal.Here is the output from a little test i just ran :

 pull started Sat Aug 7 10:32:03 BST 2010
===
New directory is /opt/FlightGear/fgdata
>From git://gitorious.org/fg/fgdata
   33b8fe6..74ec1cd  master -> origin/master
Updating 33b8fe6..74ec1cd
Fast-forward
 Aircraft/737-300/Models/contrail.xml   |  216 +-
 Aircraft/C130/Models/main.xml  |   33 +
 Aircraft/Concorde/Concorde-set.xml |8 +-
 Aircraft/Concorde/Models/Concorde_ba.xml   |   21 +
 Aircraft/Concorde/Models/Effects/contrail-new.xml  |  142 +
 Aircraft/Concorde/Models/Effects/contrail1.eff |  156 +
 Aircraft/Concorde/Models/Effects/contrail2.eff |  151 +
 .../Concorde/Models/Effects/contrail_dummy.xml |   11 +
 .../Concorde/Models/Effects/contrail_shader1.xml   |   35 +
 .../Concorde/Models/Effects/contrail_shader2.xml   |   35 +
 Aircraft/Concorde/Models/Effects/smoke.png |  Bin 0 -> 6482
bytes
 Aircraft/Concorde/concorde-submodels.xml   |   28 +
 Aircraft/Concorde/concorde-subsubmodels.xml|   66 +
 Aircraft/Concorde/concorde-subsubsubmodels.xml |   67 +
 Aircraft/Concorde/concorde-subsubsubsubmodels.xml  |   64 +
 Aircraft/Short_Empire/Models/Interior/interior.ac  | 8138
+---
 Aircraft/Short_Empire/Models/Interior/interior.xml |  312 +-
 .../Short_Empire/Models/Interior/spar_panel.xml|   10 +-
 Aircraft/Short_Empire/Short_Empire-set.xml |   25 +-
 Aircraft/Short_Empire/Short_S23.xml|   59 +-
 Aircraft/Short_Empire/Systems/fuel-system.xml  |   20 +-
 Aircraft/Short_Empire/Systems/short-empire.nas |   11 +-
 22 files changed, 8171 insertions(+), 1437 deletions(-)
 create mode 100644 Aircraft/Concorde/Models/Effects/contrail-new.xml
 create mode 100644 Aircraft/Concorde/Models/Effects/contrail1.eff
 create mode 100644 Aircraft/Concorde/Models/Effects/contrail2.eff
 create mode 100644 Aircraft/Concorde/Models/Effects/contrail_dummy.xml
 create mode 100644
Aircraft/Concorde/Models/Effects/contrail_shader1.xml
 create mode 100644
Aircraft/Concorde/Models/Effects/contrail_shader2.xml
 create mode 100644 Aircraft/Concorde/Models/Effects/smoke.png
 create mode 100644 Aircraft/Concorde/concorde-submodels.xml
 create mode 100644 Aircraft/Concorde/concorde-subsubmodels.xml
 create mode 100644 Aircraft/Concorde/concorde-subsubsubmodels.xml
 create mode 100644 Aircraft/Concorde/concorde-subsubsubsubmodels.xml
===
pull ended Sat Aug 7 10:32:40 BST 2010
fgdata git pull took 0 mins 37 seconds

===
My connection is BT Broadband, nominally 12 Mbps, but actually 7,616
Kbps.
My machine is based on a 2x AMD Athlon(tm) 7450 Dual-Core Processor
with 2 GB mem.

Kind regards,
Aasdair


--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT and FGDATA

[Hal V. Engel]

On Saturday 07 August 2010 11:45:04 am Vivian Meazza wrote:
> Alan Teeder wrote
> 
> > --
> > From: "Alasdair" 
> > Sent: Saturday, August 07, 2010 10:47 AM
> > To: "FlightGear developers discussions"
> > 
> > Cc: 
> > Subject: Re: [Flightgear-devel] GIT and FGDATA
> >
> > > On Fri, 2010-08-06 at 07:59 -0600, dave perry wrote:
> > >> I am not seeing the slowdown.  I just ran a simple script that updates
> > >> simgear, flightgear source, and fgdata.  I would estimate that the
> > >> "git pull origin" run in fgdata took about 3 minutes.  This
> > >> performance has been typical for me.  I  ran System Monitor (F12)
> > >> during the fgdata
> >
> > pull
> >
> > >> and the data rate was between 96 and 100 KB/s and the memory usage was
> > >> constant.  I connect via Earthlink dsl.
> > >>
> > >> Dave P.
> > >
> > > I experience much the same as Dave. A git pull in fgdata is no big
> > > deal.Here is the output from a little test i just ran :
> > >
> > > pull started Sat Aug 7 10:32:03 BST 2010
> > > ===
> > > New directory is /opt/FlightGear/fgdata
> > >
> > >>From git://gitorious.org/fg/fgdata
> > >
> > >   33b8fe6..74ec1cd  master -> origin/master
> > > Updating 33b8fe6..74ec1cd
> > > Fast-forward
> > > Aircraft/737-300/Models/contrail.xml   |  216 +-
> > > Aircraft/C130/Models/main.xml  |   33 +
> > > Aircraft/Concorde/Concorde-set.xml |8 +-
> > > Aircraft/Concorde/Models/Concorde_ba.xml   |   21 +
> > > Aircraft/Concorde/Models/Effects/contrail-new.xml  |  142 +
> > > Aircraft/Concorde/Models/Effects/contrail1.eff |  156 +
> > > Aircraft/Concorde/Models/Effects/contrail2.eff |  151 +
> > > .../Concorde/Models/Effects/contrail_dummy.xml |   11 +
> > > .../Concorde/Models/Effects/contrail_shader1.xml   |   35 +
> > > .../Concorde/Models/Effects/contrail_shader2.xml   |   35 +
> > > Aircraft/Concorde/Models/Effects/smoke.png |  Bin 0 -> 6482
> > > bytes
> > > Aircraft/Concorde/concorde-submodels.xml   |   28 +
> > > Aircraft/Concorde/concorde-subsubmodels.xml|   66 +
> > > Aircraft/Concorde/concorde-subsubsubmodels.xml |   67 +
> > > Aircraft/Concorde/concorde-subsubsubsubmodels.xml  |   64 +
> > > Aircraft/Short_Empire/Models/Interior/interior.ac  | 8138
> > > +---
> > > Aircraft/Short_Empire/Models/Interior/interior.xml |  312 +-
> > > .../Short_Empire/Models/Interior/spar_panel.xml|   10 +-
> > > Aircraft/Short_Empire/Short_Empire-set.xml |   25 +-
> > > Aircraft/Short_Empire/Short_S23.xml|   59 +-
> > > Aircraft/Short_Empire/Systems/fuel-system.xml  |   20 +-
> > > Aircraft/Short_Empire/Systems/short-empire.nas |   11 +-
> > > 22 files changed, 8171 insertions(+), 1437 deletions(-)
> > > create mode 100644 Aircraft/Concorde/Models/Effects/contrail-new.xml
> > > create mode 100644 Aircraft/Concorde/Models/Effects/contrail1.eff
> > > create mode 100644 Aircraft/Concorde/Models/Effects/contrail2.eff
> > > create mode 100644 Aircraft/Concorde/Models/Effects/contrail_dummy.xml
> > > create mode 100644
> > > Aircraft/Concorde/Models/Effects/contrail_shader1.xml
> > > create mode 100644
> > > Aircraft/Concorde/Models/Effects/contrail_shader2.xml
> > > create mode 100644 Aircraft/Concorde/Models/Effects/smoke.png
> > > create mode 100644 Aircraft/Concorde/concorde-submodels.xml
> > > create mode 100644 Aircraft/Concorde/concorde-subsubmodels.xml
> > > create mode 100644 Aircraft/Concorde/concorde-subsubsubmodels.xml
> > > create mode 100644 Aircraft/Concorde/concorde-subsubsubsubmodels.xml
> > > ===
> > > pull ended Sat Aug 7 10:32:40 BST 2010
> > > fgdata git pull took 0 mins 37 seconds
> > >
> > > ===
> > > My connection is BT Broadband, nominally 12 Mbps, but actually 7,616
> > > Kbps.
> > > My machine is based on a 2x AMD Athlon(tm) 7450 Dual-Core Processor
> > > with 2 GB mem.
> > >
> > > Kind regards,
> > > Aasdair
> >
> > I have just done a very quick and successful fgdata git pull using
> > Cygwin. The result

Re: [Flightgear-devel] GIT and FGDATA

[Vivian Meazza]

Hal V. Engel wrote

> 
> On Saturday 07 August 2010 11:45:04 am Vivian Meazza wrote:
> > Alan Teeder wrote
> >
> > > --
> > > From: "Alasdair" 
> > > Sent: Saturday, August 07, 2010 10:47 AM
> > > To: "FlightGear developers discussions"
> > > 
> > > Cc: 
> > > Subject: Re: [Flightgear-devel] GIT and FGDATA
> > >
> > > > On Fri, 2010-08-06 at 07:59 -0600, dave perry wrote:
> > > >> I am not seeing the slowdown.  I just ran a simple script that
> updates
> > > >> simgear, flightgear source, and fgdata.  I would estimate that the
> > > >> "git pull origin" run in fgdata took about 3 minutes.  This
> > > >> performance has been typical for me.  I  ran System Monitor (F12)
> > > >> during the fgdata
> > >
> > > pull
> > >
> > > >> and the data rate was between 96 and 100 KB/s and the memory usage
> was
> > > >> constant.  I connect via Earthlink dsl.
> > > >>
> > > >> Dave P.
> > > >
> > > > I experience much the same as Dave. A git pull in fgdata is no big
> > > > deal.Here is the output from a little test i just ran :
> > > >
> > > > pull started Sat Aug 7 10:32:03 BST 2010
> > > > ===
> > > > New directory is /opt/FlightGear/fgdata
> > > >
> > > >>From git://gitorious.org/fg/fgdata
> > > >
> > > >   33b8fe6..74ec1cd  master -> origin/master
> > > > Updating 33b8fe6..74ec1cd
> > > > Fast-forward
> > > > Aircraft/737-300/Models/contrail.xml   |  216 +-
> > > > Aircraft/C130/Models/main.xml  |   33 +
> > > > Aircraft/Concorde/Concorde-set.xml |8 +-
> > > > Aircraft/Concorde/Models/Concorde_ba.xml   |   21 +
> > > > Aircraft/Concorde/Models/Effects/contrail-new.xml  |  142 +
> > > > Aircraft/Concorde/Models/Effects/contrail1.eff |  156 +
> > > > Aircraft/Concorde/Models/Effects/contrail2.eff |  151 +
> > > > .../Concorde/Models/Effects/contrail_dummy.xml |   11 +
> > > > .../Concorde/Models/Effects/contrail_shader1.xml   |   35 +
> > > > .../Concorde/Models/Effects/contrail_shader2.xml   |   35 +
> > > > Aircraft/Concorde/Models/Effects/smoke.png |  Bin 0 -> 6482
> > > > bytes
> > > > Aircraft/Concorde/concorde-submodels.xml   |   28 +
> > > > Aircraft/Concorde/concorde-subsubmodels.xml|   66 +
> > > > Aircraft/Concorde/concorde-subsubsubmodels.xml |   67 +
> > > > Aircraft/Concorde/concorde-subsubsubsubmodels.xml  |   64 +
> > > > Aircraft/Short_Empire/Models/Interior/interior.ac  | 8138
> > > > +---
> > > > Aircraft/Short_Empire/Models/Interior/interior.xml |  312 +-
> > > > .../Short_Empire/Models/Interior/spar_panel.xml|   10 +-
> > > > Aircraft/Short_Empire/Short_Empire-set.xml |   25 +-
> > > > Aircraft/Short_Empire/Short_S23.xml|   59 +-
> > > > Aircraft/Short_Empire/Systems/fuel-system.xml  |   20 +-
> > > > Aircraft/Short_Empire/Systems/short-empire.nas |   11 +-
> > > > 22 files changed, 8171 insertions(+), 1437 deletions(-)
> > > > create mode 100644 Aircraft/Concorde/Models/Effects/contrail-new.xml
> > > > create mode 100644 Aircraft/Concorde/Models/Effects/contrail1.eff
> > > > create mode 100644 Aircraft/Concorde/Models/Effects/contrail2.eff
> > > > create mode 100644
> Aircraft/Concorde/Models/Effects/contrail_dummy.xml
> > > > create mode 100644
> > > > Aircraft/Concorde/Models/Effects/contrail_shader1.xml
> > > > create mode 100644
> > > > Aircraft/Concorde/Models/Effects/contrail_shader2.xml
> > > > create mode 100644 Aircraft/Concorde/Models/Effects/smoke.png
> > > > create mode 100644 Aircraft/Concorde/concorde-submodels.xml
> > > > create mode 100644 Aircraft/Concorde/concorde-subsubmodels.xml
> > > > create mode 100644 Aircraft/Concorde/concorde-subsubsubmodels.xml
> > > > create mode 100644 Aircraft/Concorde/concorde-subsubsubsubmodels.xml
> > > > ===
> > > > pull ended Sat Aug 7 10:32:40 BST 2010
> > > > fgdata git pull took 0 mins 37 seconds
> > > &

Re: [Flightgear-devel] fgdata is frozen!

[TDO_Brandano -]

I guess that the aircrafts will just end up "deleted" in the next pull, leaving 
the rest of FGDATA untouched. However, FGFS already supports a different path 
for aircrafts, so it should be pretty simple to get everything running as 
usual. Just copy the planes to another folder before the next pull. The 
medicine might be slightly bitter, but you will feel a lot better after it, 
methinks.

Ciao  (because I can),
Alessandro

From: curtol...@gmail.com
Date: Sun, 16 Oct 2011 16:30:11 -0500
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] fgdata is frozen!

Hi Thorsten,
One question: if we have our own local branches of the fgdata repository for 
our own experimentation, will it be straightforward to hang these off the new 
repository?


Thanks,
Curt.

On Sun, Oct 16, 2011 at 2:31 PM, ThorstenB wrote:


Jorg and Gijs are working on the new fgdata repo now.

Therefore the existing fgdata repo is frozen as of now - even commit

privileges are removed - hopefully permanently for the (historic) fgdata

repo.



They'll start a new (temporary) repository. Once the new repo is all

setup and working as expected, we'll switch (shuffle the names) and add

committers.



cheers,

Thorsten



--

All the data continuously generated in your IT infrastructure contains a

definitive record of customers, application performance, security

threats, fraudulent activity and more. Splunk takes this data and makes

sense of it. Business sense. IT sense. Common sense.

http://p.sf.net/sfu/splunk-d2d-oct

___

Flightgear-devel mailing list

Flightgear-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/flightgear-devel



-- 
Curtis Olson:http://www.atiak.com - http://aem.umn.edu/~uav/

http://www.flightgear.org - http://gallinazo.flightgear.org



--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel   
  --
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Splitting fgdata

[Roland Häder]

Hi,

you can download my fgdata bundle from here [1]. You can (and should)
verify it with provided hashes and signature (GPG). After that you can
extract it with gitbundle (or so). The usage of that tool should be
widely documented.

Anyway, I like your idea (and many others here as well) because it
limits the fgdata repository only to the minimum-needed files to launch
FGFS.

Regards,
Roland

[1]: http://flightgear.mxchange.org/fgdata-bundle.html

On Wed, 2011-04-20 at 21:48 +0200, Cedric Sodhi wrote:
> Dear Subscribers,
> 
> I'm in the unfortunate situation that I want to build from GIT and
> therefore need the fgdata. But despite my rather good (20Mbs) connection
> it's impossible for me to obtain the whole repository from scratch. It's
> about 8.4 Gigabytes, I can rightfully assume one of the biggest
> repositories that GIT has ever seen and, for just the size of the data
> without history, probably the biggest there exist.
> [...]


signature.asc
Description: This is a digitally signed message part
--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] fgdata is frozen!

[Curtis Olson]

Hi Thorsten,

One question: if we have our own local branches of the fgdata repository for
our own experimentation, will it be straightforward to hang these off the
new repository?

Thanks,

Curt.


On Sun, Oct 16, 2011 at 2:31 PM, ThorstenB wrote:

> Jorg and Gijs are working on the new fgdata repo now.
> Therefore the existing fgdata repo is frozen as of now - even commit
> privileges are removed - hopefully permanently for the (historic) fgdata
> repo.
>
> They'll start a new (temporary) repository. Once the new repo is all
> setup and working as expected, we'll switch (shuffle the names) and add
> committers.
>
> cheers,
> Thorsten
>
>
> --
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>



-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT add airplane/scenery

[Durk Talsma]

As far as my (still limited) understanding goes, gitorious needs to know the 
public SSH key of the machine you're uploading from.  Just login at gitorious, 
go to dashboard, and click Manage SSH keys.

HTH,
Durk

On 03 Nov 2011, at 09:03, Michael Sgier wrote:

> Ok I did a fgdata clone:
> 
> https://gitorious.org/~scrat/fg/scrats-fgdata
> 
> 
> 
> and pulled that ~3.5GB. Now I've added the aircrafts but push gives:
> 
> 
> 
> michael@ubuntu:/media/DATA/FGFS/install/fgfs/fgdata$ git push origin master
> fatal: protocol error: expected sha/ref, got '
> --
> The git:// protocol is read-only.
> 
> Please use the push url as listed on the repository page.
> ------'
> michael@ubuntu:/media/DATA/FGFS/install/fgfs/fgdata$ git push 
> git://gitorious.org/~scrat/fg/scrats-fgdata.git
> fatal: protocol error: expected sha/ref, got '
> --
> The git:// protocol is read-only.
> 
> Please use the push url as listed on the repository page.
> --'
> 
> 
> 
> 
> 
> Thanks again. fgdata is still not splitted? It also seems to be incompatible 
> 
> to my fgfs git...maybe need to update that as well?
> 
> 
> 
> 
> 
> 
> 
> --
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Release 2.8.0: feature freeze starts now

[ThorstenB]

Am 17.06.2012 21:14, schrieb Torsten Dreyer:
> today is June, 17th and this marks our feature freeze for the sources of
> SimGear, FlightGear and FGDATA. Within FGDATA, only aircraft not being
> part of the base package are not part of the feature freeze. Maintainers
> for those aircraft are kindly requested to carefully check not to update
> _any_ file outside their individual aircraft's root directory.

In order to prepare building the first "2.8.0" release candidate(s), we 
have now updated the simgear/flightgear/fgdata version in the git 
repositories - to version 2.8.0.

Note, the release candidate sources are still in the frozen "next" 
branches ("master" for fgdata). On July 17th we'll move 2.8.0 to a 
separate branch, reopen "next" for development and bump its version 
again (to 2.9.0).

See: http://wiki.flightgear.org/Release_plan

(The version change was pushed to sg/fg/fgdata consistently. If you get 
a version mismatch, make sure you have pulled all three repos, rebuilt 
and _installed_ sg + fg. If you still get a version mismatch, try a 
clean build - and _install_.)

cheers,
Thorsten

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Olaf Flebbe]

Hi,

I did some experiments both with hg and git, and collecting responses.

IMHO there is no real technical point to prefer one of DVCS'es.

* Tim Moore told us gitorious have push too.
* msysgit is a little bit better integrated in Windows -- for instance 
simpler file name mapping.
* with tortoisegit even a GUI exist
* At mapserv a fgdata a git repository of data exists for some time.
   (The bare repository itself is a little bit smaller than the CVS 
checkout itself)
* Checkout of fgdata worked flawless with Windows. Updating fgdata is 
much faster than CVS

Additionaly:

* hg can work with fgdata, too: Its repository is marginaly larger 
compared to git
* I had no time to actually upload fgdata-hg to somewhere else
* (tortoisehg exists)

Given the existing infrastructure for git services, no objections from 
me against git (any more).

We should step further and discuss on how a transition can be made. BTW 
I would vote for the gitorious system.

Greetings
Olaf

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git of fgdata today

[Donn Washburn]

On 12/23/2010 01:14 PM, Torsten Dreyer wrote:
> Am 23.12.10 19:35, schrieb Donn Washburn:
>> On 12/23/2010 12:24 PM, Gijs de Rooy wrote:
>>>> FGDATA site seems to be down or have problems.  I have tried about 5
>>>> times over time to get fgdata with the same error.
>>> Gitorious was down since earlier today. However, it appears to be up
>>> again now.
>>>
>>> You can still obtain fgdata from the mapserver clone though, if
>>> Gitorious still doesn't
>>> work: http://mapserver.flightgear.org/git/?p=fgdata;a=summary
>>>
>>> Cheers,
>>> Gijs
>> Thanks that seems to be working. It even seems faster
>>
> I saw many reports that mapserver is a faster than gitorious. Thanks,
> Martin!
>
> Torsten (also bmw biker ;-)
I BMW Rider;

Me Also for over 30 years a 300,000 miles until recently.  Still have 
the 1987 K100LT In great shape

-- 
73 de Donn Washburn
307 Savoy Street Email:" n5...@comcast.net "
Sugar Land, TX 77478 LL# 1.281.242.3256
Ham Callsign N5XWB   HAMs : " n5...@arrl.net "
VoIP via Gizmo: bmw_87kbike / via Skype: n5xwbg
BMW MOA #: 4146 - Ambassador
   " http://counter.li.org " #279316


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

Re: [Flightgear-devel] FGData New Structure

[Vivian Meazza]

Cedric wrote

> 
> I hope this is the last time we will have to discuss this topic, since
> over the last months it seemed that everyone agreed with that FGDATA
> 
> - has to be split sometime
> - should be split a.s.a.p.
> 
> We agreed that after the current release of 2.4 would be a good point to
> get the project on the way. As I offered and it still stands, I will
> take care of writing the bash script which "splits" the current FGDATA
> repository into multiple repositories and leaves an FGDATA repository
> which holds merely the bare essentials which supplement the core binary
> of fgfs. One could classify the contents of the new FGDATA by saying
> that it's data which provides the technical backbone - the common
> denominator everything is based upon.
> 
> I'd like to cease this opportunity to give everyone the chance to utter
> their possible disagreement with the project or their respective
> opinions and discuss the very details of the split, which have not yet
> been determined.
> 
> The general boundary conditions of the splitting process are the
> following:
> 
> - FGDATA shall consist of everything which is essential for the binary
>   to run and shall not hold any data which is specific to certain
>   airports or airplanes. Those should be provided in separate
>   repositories the structure of which is not of current interest and
>   might possibly be chosen by the respective authors.
> 
> - The change shall not require restructuring of the architecture,
>   including the directory structure. Solely the repositories in which
>   the data is contained shall change.
> 
> Informatively, I'd like to supply a sensible suggestion for how a final
> structure might look and how, either as a developer or user might use
> it. Particularily, because some of you might wonder how we can strip
> FGDATA of KSFO and the 172p, leaving nothing to fly with - isn't that a
> bad decision?
> 
> Definitly not. One has to distinguish between a proper, dedicated
> development structure which is aligned to and substructred into
> independent development units and a way of deployment.
> 
> As a developer, you will clone the base fgfs SC repository and you will
> clone the FGDATA repository. Then, depending on your field of interest
> you will clone the aircrafts, airports etc. you are planning to work on.
> 
> You can do so with the git submodule, which will integrate the specific
> aircraft/airport/etc repository into the existing FGDATA repository,
> while keeping the commits separate.
> 
> For deployment, you either manually or programatically git-submodule all
> data required for shipping into a branch for deployment. This includes,
> for instance, the KSFO tile and the c172p. It's apparent that one, among
> many advantages of that approach is, that the confusing redundancy
> between the "default KSFO" and the "scenery KSFO", as it currently
> exists, will go.
> 
> While the planes are the primary concern of the splitting and will bring
> a relief of a tremendous 4.5 Gigabytes to every user of FGDATA and
> rectify a lot of redundancies and confusion, other things might also be
> considered, say, ./Traffic (just a lucky guess).
> 
> Practically everything which is orthogonal to the core and without which
> FG (assuming a plane and a tile) can properly run, should migrate.
> 

I think this is an offer we can't refuse. I think these proposals are as
good as any, and are in line with what Tim Moore was doing. Perhaps we
should go for a phased approach. In the fist phase, we could split out the
aircraft, then further restructuring could form subsequent phases.

Cedric might like to start work on his script as soon as possible.

Vivian 



--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] request for FGDATA commit please.

[Gijs de Rooy]

> So could someone with commit rights to fgdata please replace the A380 
> aircraft by;

Done: 
http://gitorious.org/fg/fgdata/commit/05721b5fb2d374adf80ec6cf4e05ba4e66012e8a
Please check if all went well.
 
Cheers,
Gijs  --
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] RFC: fgdata merge request 76: Improved airport Textures

[Durk Talsma]

Whoops,

should have been: (request #61).

https://gitorious.org/fg/fgdata/merge_requests/61

(Need more coffee, need more coffee, need more coffeee . :-) )

D.

On 07 May 2011, at 10:35, Durk Talsma wrote:

> Hi all,
> 
> Going through the list of open merge requests for fgdata, I noticed that this 
> one is still open:
> 
> https://gitorious.org/fg/fgdata/merge_requests/76
> 
> One person, other than the author commented positively on the new textures in 
> question (in addition to receiving generally positive comments on the forum), 
> so I would be inclined to accept this merge request, but I cannot really 
> judge if there are any side effects? Any objections?
> 
> Cheers,
> Durk

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] some models updates available

[grtuxhangar team]

Hello, Stuart

No, it is not your mistake, it is only the wrong process we are using,
regarding the Flightgear fgdata  content , regarding  how it must be used.
Unfortunately we are  working with  56000 kbs  speed communication line
when we can :(

To us fgdata is a "monster".
Downloading data from it is only possible with the process described there
( tricky but working ):
http://www.flightgear.org/forums/viewtopic.php?f=4&t=10420

Thus a  merge request to fgdata which would be easier for you is not
possible.


Thank

Ahmad



On 12 July 2013 15:54, Stuart Buchanan  wrote:

> On Fri, Jul 12, 2013 at 12:52 PM, grtuxhangar team wrote:
> > Hello,Stuart
> >
> > Sorry for the huge mistake, thank a lot for the fix, and the time you
> spent
> > on it.
> > However, when looking at the
> > http://www.gitorious.org/fg/fgdata/trees/master/Aircraft/F-8E-Crusader
> > and
> > http://www.gitorious.org/fg/fgdata/trees/master/Aircraft/PBY-Catalina
> > I notice there is a lot of old outdated files which are longer there (
> > especially textures.rgb  files ).
> > Our updated versions within the https://gitorious.org/eekpo, do not
> contains
> > these old files.
>
> Ah, that's my mistake.
>
> To avoid .git files corrupting each other, I downloaded your new version
> as a
> tarball from gitorious and then copied it over the existing aircraft.
> Of course,
> that wouldn't have deleted the removed files.
>
> I'll do another clean up when I get a chance over the weekend.  No problem.
>
> > The process we are working with are surely wrong  to you.
> > When we are working on updates what is the best way  to help you ?
> >  How could we help you to synchronize those updates within fgdata. ?
>
> A merge request to fgdata would be easier for me to handle, but that would
> mean you have to download the full fgdata.
>
> On Fri, Jul 12, 2013 at 2:40 PM, Gijs de Rooy wrote:
> > What I always do when I get update packages instead of merge requests is
> to
> > delete the aircraft locally (not in Git) and then add the new package.
> That
> > way you will clearly see all deleted files, renamed case-insensitive
> files
> > etc.
>
> Good tip!  I'll try to remember to do that next time.
>
> -Stuart
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] RFC: fgdata merge request 76: Improvedairport Textures

[Vivian Meazza]

I'm afraid that the "improved textures" really aren't an improvement. Not
only do they not work for taxiways, we have also lost the chevrons at the
threshold that were quite recently added: 

 

https://picasaweb.google.com/gijsrooy/FlightGearSkyopSTextures#5604420979421
192098 

 

The grass isn't much of an improvement either. On balance, this upload is a
regression. IMO we should back it out.

 

Vivian

 

-Original Message-
From: Durk Talsma [mailto:durkt...@gmail.com] 
Sent: 07 May 2011 09:39
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] RFC: fgdata merge request 76:
Improvedairport Textures

 

Whoops,

should have been: (request #61).

https://gitorious.org/fg/fgdata/merge_requests/61

(Need more coffee, need more coffee, need more coffeee . :-) )

D.

 

On 07 May 2011, at 10:35, Durk Talsma wrote:





Hi all,

Going through the list of open merge requests for fgdata, I noticed that
this one is still open:

https://gitorious.org/fg/fgdata/merge_requests/76

One person, other than the author commented positively on the new textures
in question (in addition to receiving generally positive comments on the
forum), so I would be inclined to accept this merge request, but I cannot
really judge if there are any side effects? Any objections?

Cheers,
Durk

 

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Gijs de Rooy]

> Torsten wrote:
> git clone g...@gitorious.org:fg/fgdata-new data

Make sure you don't forget .git. Use this: git clone 
g...@gitorious.org:fg/fgdata-new.git data

  --
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] attitude indicator in fgdata aircraft

[syd adams]

thanks for the heads up ... Im currently updating the CitationX so
i'll fix that and check my other aircraft.
You said fgdata , does that mean aircraft are back in fgdata ?Is the
separation idea abandoned for now? Just asking so i know how to
proceed , since im updating mine in the FG-Aircraft repository.
Thanks.

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] fgdata trouble

[ThorstenB]

On 21 Sep 2012, at 13:03, Anders Gidenstam wrote:
> The master branch of fgdata has become messed up. A number of commits
> have become duplicated and some undone (they exist in the history but
> their effect is gone from HEAD).

It has happened again, fgdata history is messed up. It looks as if my 
last commits (6d46fe7, f722671) were applied to fgdata multiple times 
now (duplicates are 818b92f and e7452f7). With gitk itself, I can't even 
see how where these originated (looks as if I had pushed them multiple 
times). Only the gitorious.org history shows that these were indeed not 
pushed by me:

https://www.gitorious.org/fg/fgdata/commit/818b92fa07a49c333f80ac21f483b33fd5e2b7c7

https://www.gitorious.org/fg/fgdata/commit/e7452f70358e67824e499294fd32d6d6f8d3dd93

Can we please make it a requirement that _local_ merge operations must 
not become visible on our public repository, so _everyone_ has to 
"rebase" before pushing anything?

The only merge/branch operations that should be visible in our public 
repo should be those that affect public branches (release branch 
creation/merges etc).

There's really no reason why other people should see that user XYZ has 
merged his local branch 1-15 times with gitorious, before pushing back. 
It only results in the git history becoming unreadable. And apparently 
it results in more issues.

If you compare simgear's or flightgear's history with fgdata's history, 
you'll see how nice and readable a git history can be - since obviously 
(almost) everyone pushing to sg/fg knows hows how to rebase.

Resolving merge operations locally, to reorder and cleanup the history 
is really simple - and only requires a few seconds. If you have 
uncommited changes in your local directory, you can temporarily stash 
them - so that "rebase" won't complain.

For fgdata:
git stash
git rebase origin/master
git stash pop

(And for simgear/flightgear:
git stash
git rebase origin/next
git stash pop
)

It is also a good idea to check the git history (gitk) before pushing to 
gitorious: you can read and double check your own changes a final time - 
and also check the history for local merge or funny duplication issues. 
If you're having local Git trouble (like duplications), *please* ask 
before pushing to gitorious.

cheers,
Thorsten

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] c172p UI Changes

[Geoff McLane]

Hi James, 

Did a git pull SG/FG/fgdata a few hours ago,
and a Release re-build in Windows 7... and took the 
default c172p for spin...

I had been reading about your changes, but I 
was in for some surprises ;=)) And I understand 
it is a WIP...

While I like the cursor changes to <--> when you 
hover over a knob, it seem now the knob only turns 
one way, unless you hold the Alt key down...

Previously you just shifted to the left or right 
of the knob for this direction change...

Is that the expected UI change? Or am I missing 
something...

Then the compass bug starts clockwise - faster 
if you hold shift... unless with the Alt key...
like the altimeter...

And the magnetos clockwise, but could not engage 
starter with mouse...

But the compass knob goes anticlockwise, like the 2 
ADF... each reversed on Alt key... and each faster 
with Shift...

So I can understand they turn one way unless the 
Alt key is held, then the other way... but could 
they not all default to the SAME direction, say 
clockwise, and the Alt key reverse that?

Or I suppose you could commit the default direction 
to memory ;=)) like background compass plates default 
anti, while foreground needles and bugs clockwise...

Panel lights seemed to be move right to brighten,
move left to dim, rather than clicks...

Could not operate the flaps level with the mouse, 
but had never tried with the mouse before, so 
maybe that stayed the same?

Also like the 'hand' for buttons, and vertical 
up-down arrow over switches... Did not have time 
to explore more tonight... but in general it 
'felt' good. Thanks...

Did get some nasal errors to the console -
Nasal runtime error: nil used in numeric context
  at C:/FG/fgdata/Nasal/geo.nas, line 241
  called from: C:/FG/fgdata/Nasal/canvas/tooltip.nas, line 167
  called from: C:/FG/fgdata/Nasal/canvas/tooltip.nas, line 119
  called from: C:/FG/fgdata/Nasal/canvas/tooltip.nas, line 91
  called from: C:/FG/fgdata/Nasal/canvas/tooltip.nas, line 270
  called from: C:/FG/fgdata/Nasal/canvas/tooltip.nas, line 313

Just some user feedback. HTH.

Regards,
Geoff.



--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] fgdata merge request #72

[Gijs de Rooy]

> Hal wrote: 
> I just put in another merge request for the p51d. 
> 
> Could someone please merge this into fgdata master.

Done. Error comments at http://gitorious.org/fg/fgdata/merge_requests/72
  --
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] Nonfunctional airplanes

[Anders Gidenstam]

On Thu, 25 Nov 2010, thorsten.i.r...@jyu.fi wrote:

> I did (naively perhaps) change some files inside fgdata, and indeed
>
> git status
>
> gave a list of precisely those files as out of sync - which didn't really
> worry me. But evidence suggests that in fact a lot more was not updated
> for whatever reason.
>
> So what did I do wrong, and what should I do differently in the future?

git will not merge anything into your local branch when it 
contains uncommitted changes. git pull ought to have complained about 
that. (And it sure does here.)

So commit your local changes to your local branch, then you can
synchronize with upstream using

git pull master-fgdata master

or

git fetch master-fgdata
git rebase remotes/master-fgdata/master

I prefer the latter as that keeps my local changes last in the commit 
graph.

I also recommend creating a named remote for the master repository.
git remote add master-fgdata git://gitorious.org/fg/fgdata.git

(You could name it origin to cut the ties to the bundle and make the 
repository behave more normal.)

Cheers,

Anders
-- 
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/

--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository

[Tim Moore]

I've started the first phase of trimming down fgdata. I've removed the
an2 from fgdata and put it in its own repository called "ac-an2" under
the Flightgear project. I'm going to proceed with moving other
aircraft which haven't been touched in a while into their own repos as
well. When we get down to a working set of aircraft that are currently
under development, I will turn off commit rights in fgdata for a short
period while I extract those aircraft. I will then regenerate fgdata
without the history of all the aircraft, which will shrink the fgdata
repository a great deal.

I've started putting "ac-" in front of the aircraft repository names
in order to aid tools that manage aircraft downloads, etc.

Aircraft developers: please don't add new aircraft to fgdata! You can
easily set up your own repositories on gitorious and later request
that we "incorporate" a repository into the Flightgear project.

Tim

On Thu, Aug 4, 2011 at 9:53 PM, Martin Spott  wrote:
> Frederic Bouvier wrote:
>
>> Funny (!) that the last one in the first list will be unmaintain from
>> now if I read this ml correctly.
>
> Let's sit down and have a beer/wine/tea/vos...dka  ;-)
>
>        Martin.
> --
>  Unix _IS_ user friendly - it's just selective about who its friends are !
> --
>
> --
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. 
http://p.sf.net/sfu/wandisco-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after

[Anders Gidenstam]

On Thu, 20 Oct 2011, Martin Spott wrote:


Jari Häkkinen wrote:


I support the split if only for the reason that aircraft maintainers
will get commit rights to their private spheres in fg-land (if I
understand things properly). With the previous monolithic fgdata only a
selected group of people had commit privileges.


Maybe now, that 'fgdata' is open again, one of the admins should simply
add Jari to the list of data maintainers  ;-)


Still, that is a point in favour of having aircraft in separate 
repositories. Already with our selected group there as been some scary git 
moments, e.g. at one point a commit adding a new aircraft was undone in a 
tangled mess of merges and remerges by other committers - but I do 
sincerely hope that was only possible due to Tim having forgot to 
forbid non-fastforward updates on fgdata at that point (which was 
the case IIRC).


An other thing: we know a 4GB repository works well on at least some 
platforms (e.g. I have had no problems) but what size is too large?

8GB? 16GB?
Nevermind, keeping everything in one repository we are likely to hit 
that size sooner than if we scale in the number of repositories instead. 
The latter carries its own problems as has been mentioned, however.



Amazingly, having both the new (experimental) and old fgdata master 
branches in my git repository the size has not increased much:


anders@sleipner:~/FlightGear/fgdata$ du -sk .git
4022072 .git

The level of compression achieved by git is impressive, but no doubt 
helped by the identical deltas on the respective branches.



Cheers,

Anders
--
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/
 http://gitorious.org/anders-hangar--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Ciosco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] New alpha version of download_and_compile.sh - avoids multiple fgdata downloads.

[Pat]

Any date or version will serve.

Here's how to do it:

1. Create a new work directory for fg builds you are going to use the
next/experimental version on. Mine is ~/work/fg

2. In the new work directory, place a copy of the experimental
download_and_compile.sh

3. Create directories for the versions of fgdata you are going to need:

~/work/fg/fgdata_2.11.0
~/work/fg/fgdata_2.10.0
~/work/fg/fgdata_2.8.0

Depending on how much you like to test, you can create just one
of these and copy -R your downloaded copy into it. Or you can
copy -R into all three. The script should be able to handle it
either way. Also, it should not matter which version you put in
these directories. The script should be able to reset them to
the right version when a build is done for that version.

So far, everything is in your new work directory.  Builds
happen one level down.

4.  Create a directory for the build you want to do

~/work/fg/master
~/work/fg/next
~/work/fg/stable
~/work/fg/2.10.0
~/work/fg/2.8.0

5.  cd to the directory you want to build and do the right build

for example:


cd ~/work/fg/next
../download_and_compile.sh -p n -d y -xv all

cd !/work/fg/2.10.0
../download_and_compile.sh -p n -d y -xv j 3 -B 2.10.0 -R HEAD all

Now if you have to blow away one of your build directories, fgdata stays
put, safe and sound in the top of your fg work tree.

I'm taking bets on how long it takes you to find a bug...  Happy
hunting.

-Pat

> ..to avoid the 3-day delay fetching a new 5GB copy of fgdata, 
> where do I put my "March 29'th-current" copy of fgdata?
> I now have it as 2.11.0 in ~/FG-git/fgdata 
> 


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] some models updates available

[grtuxhangar team]

oh correct not 56000 kbs  but only 56 kbs, i was dreaming


On 13 July 2013 17:13, grtuxhangar team  wrote:

> Hello, Stuart
>
> No, it is not your mistake, it is only the wrong process we are using,
> regarding the Flightgear fgdata  content , regarding  how it must be used.
> Unfortunately we are  working with  56000 kbs  speed communication line
> when we can :(
>
> To us fgdata is a "monster".
> Downloading data from it is only possible with the process described there
> ( tricky but working ):
> http://www.flightgear.org/forums/viewtopic.php?f=4&t=10420
>
> Thus a  merge request to fgdata which would be easier for you is not
> possible.
>
>
> Thank
>
> Ahmad
>
>
>
> On 12 July 2013 15:54, Stuart Buchanan  wrote:
>
>> On Fri, Jul 12, 2013 at 12:52 PM, grtuxhangar team wrote:
>> > Hello,Stuart
>> >
>> > Sorry for the huge mistake, thank a lot for the fix, and the time you
>> spent
>> > on it.
>> > However, when looking at the
>> > http://www.gitorious.org/fg/fgdata/trees/master/Aircraft/F-8E-Crusader
>> > and
>> > http://www.gitorious.org/fg/fgdata/trees/master/Aircraft/PBY-Catalina
>> > I notice there is a lot of old outdated files which are longer there (
>> > especially textures.rgb  files ).
>> > Our updated versions within the https://gitorious.org/eekpo, do not
>> contains
>> > these old files.
>>
>> Ah, that's my mistake.
>>
>> To avoid .git files corrupting each other, I downloaded your new version
>> as a
>> tarball from gitorious and then copied it over the existing aircraft.
>> Of course,
>> that wouldn't have deleted the removed files.
>>
>> I'll do another clean up when I get a chance over the weekend.  No
>> problem.
>>
>> > The process we are working with are surely wrong  to you.
>> > When we are working on updates what is the best way  to help you ?
>> >  How could we help you to synchronize those updates within fgdata. ?
>>
>> A merge request to fgdata would be easier for me to handle, but that would
>> mean you have to download the full fgdata.
>>
>> On Fri, Jul 12, 2013 at 2:40 PM, Gijs de Rooy wrote:
>> > What I always do when I get update packages instead of merge requests
>> is to
>> > delete the aircraft locally (not in Git) and then add the new package.
>> That
>> > way you will clearly see all deleted files, renamed case-insensitive
>> files
>> > etc.
>>
>> Good tip!  I'll try to remember to do that next time.
>>
>> -Stuart
>>
>>
>> --
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> ___
>> Flightgear-devel mailing list
>> Flightgear-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>>
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FGData New Structure

[Citronnier - Alexis Bory]

Le 17/09/2011 20:26, Vivian Meazza a écrit :
> Cedric wrote
>
>> I hope this is the last time we will have to discuss this topic, since
>> over the last months it seemed that everyone agreed with that FGDATA
>>
>> - has to be split sometime
>> - should be split a.s.a.p.
>>
>> We agreed that after the current release of 2.4 would be a good point to
>> get the project on the way. As I offered and it still stands, I will
>> take care of writing the bash script which "splits" the current FGDATA
>> repository into multiple repositories and leaves an FGDATA repository
>> which holds merely the bare essentials which supplement the core binary
>> of fgfs. One could classify the contents of the new FGDATA by saying
>> that it's data which provides the technical backbone - the common
>> denominator everything is based upon.
>>
>> I'd like to cease this opportunity to give everyone the chance to utter
>> their possible disagreement with the project or their respective
>> opinions and discuss the very details of the split, which have not yet
>> been determined.
>>
>> The general boundary conditions of the splitting process are the
>> following:
>>
>> - FGDATA shall consist of everything which is essential for the binary
>>to run and shall not hold any data which is specific to certain
>>airports or airplanes. Those should be provided in separate
>>repositories the structure of which is not of current interest and
>>might possibly be chosen by the respective authors.
>>
>> - The change shall not require restructuring of the architecture,
>>including the directory structure. Solely the repositories in which
>>the data is contained shall change.
>>
>> Informatively, I'd like to supply a sensible suggestion for how a final
>> structure might look and how, either as a developer or user might use
>> it. Particularily, because some of you might wonder how we can strip
>> FGDATA of KSFO and the 172p, leaving nothing to fly with - isn't that a
>> bad decision?
>>
>> Definitly not. One has to distinguish between a proper, dedicated
>> development structure which is aligned to and substructred into
>> independent development units and a way of deployment.
>>
>> As a developer, you will clone the base fgfs SC repository and you will
>> clone the FGDATA repository. Then, depending on your field of interest
>> you will clone the aircrafts, airports etc. you are planning to work on.
>>
>> You can do so with the git submodule, which will integrate the specific
>> aircraft/airport/etc repository into the existing FGDATA repository,
>> while keeping the commits separate.
>>
>> For deployment, you either manually or programatically git-submodule all
>> data required for shipping into a branch for deployment. This includes,
>> for instance, the KSFO tile and the c172p. It's apparent that one, among
>> many advantages of that approach is, that the confusing redundancy
>> between the "default KSFO" and the "scenery KSFO", as it currently
>> exists, will go.
>>
>> While the planes are the primary concern of the splitting and will bring
>> a relief of a tremendous 4.5 Gigabytes to every user of FGDATA and
>> rectify a lot of redundancies and confusion, other things might also be
>> considered, say, ./Traffic (just a lucky guess).
>>
>> Practically everything which is orthogonal to the core and without which
>> FG (assuming a plane and a tile) can properly run, should migrate.
>>
> I think this is an offer we can't refuse. I think these proposals are as
> good as any, and are in line with what Tim Moore was doing. Perhaps we
> should go for a phased approach. In the fist phase, we could split out the
> aircraft, then further restructuring could form subsequent phases.
>
> Cedric might like to start work on his script as soon as possible.
>
> Vivian

Yup !

>
> --
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> http://p.sf.net/sfu/rim-devcon-copy2
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>


--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FGData New Structure

[Cedric Sodhi]

Dear everyone,

a day late and I must admit the first version of the script really
wasn't what it was supposed to be, but here is the final version now.

Verified and tested on a small reproduction of FGData, example repo has
been uploaded[1].

The instructions have changed, no more tmpfs is required. Just browse
into your FGDATA, make sure the working dir is clean, and run the script
(which necessarily lies outside of the FGDATA dir).

There is one tiny problem which I was not entirely able to solve, that
is that not all tags appear to be sucessfully transfered. I must insist
though, that this is a negligible issue and given the project at hand,
clearly acceptable. In the worst case we will have to reset the few tags
on FGDATA were required.

In order to run the script on the example repo instead of the real
fgdata to check for yourself, you will have to change the settings
ac_dir and canonical as indicated in the first lines of the script to
the commented-out versions.

[1] http://ompldr.org/vYWZydg
#!/bin/bash

iodir="/tmp/fgsplit"
final_ac="../split_airplanes_result/"
final_fg="../split_fgdata_result/"
ac_dir="Aircraft"
canonical="origin/master"
#canonical="master"
#ac_dir="Aircrafts"
#dornot2d="-d $iodir"
bare="--bare"

echo "
Splitting FGDATA in 10 Seconds - Press Ctrl-C to cancel!

    WARNINGS 
Make _ABSOLUTELY SURE_ that you are in the right repository
Running this script in a wrong repository will have unpredictable
results!

Make sure to have $iodir mounted as tmpfs with all the storage
that you can spare, at least the size of the tree, which is 6GB

All data in the following directories will be purged, if they
already exist:
$final_ac $final_fg

  NOTE 
_NO_ irreversible changes will be made to your local repository
The resulting 'split' repositories after the spit can be found in
$final_ac
and
$final_fg
If satisfied with the results you can then delete this very repo
Which will, of course, seal the deal and make it irreversible"

sleep 10;

if ! git status ; then
echo "ERROR - Please navigate into the root of the FGDATA repository"
exit
fi

echo "Removing $final_ac $final_fg and $iodir"
rm -RI "$final_ac" "$final_fg" "$iodir"
mkdir -p "$final_ac" "$final_fg"

origin=$(pwd)

sleep 1

echo "Bringing up to date"
git pull
echo "Going onto canonical master"
git checkout "$canonical"
echo "Creating branches for all aircrafts"
for acf in "./$ac_dir/"* ; do
ac=${acf#"./$ac_dir/"}
acbn=SPLIT-$ac

if [[ "$ac" == "Generic" || "$ac" == "Instruments" || "$ac" == 
"Instruments-3d" ]] ; then
echo "Skipping $ac"
continue ;
fi

echo "Going onto canonical master"
git checkout "$canonical"
echo "Branching for $ac" ;
git branch "$acbn"
echo "Switching to new branch";
git checkout "$acbn"
echo "Isolating, please wait";
git filter-branch -f $dornot2d --subdirectory-filter "$ac_dir/$ac"
(
echo "Extracting into new repository"
cd "$final_ac"
mkdir "$ac"
cd "$ac"
git init $bare
git fetch "$origin" "$acbn"
git branch master FETCH_HEAD
)
done

echo Going onto canonical master
git checkout "$canonical"

echo "Branching for reduced FGDATA"
git branch SPLIT-CORE
git checkout SPLIT-CORE

echo "Isolating, please wait"
git filter-branch -f $dornot2d --index-filter "git rm --cached --ignore-unmatch 
$ac_dir/*"

cd $final_fg
echo "Extracting into new repository"
git init $bare
git fetch "$origin" SPLIT-CORE
git branch master FETCH_HEAD

echo "Done. Please verify the results."
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the

[Martin Spott]

The 'fgdata'-mirror at:

  http://mapserver.flightgear.org/git/gitweb.pl?p=fgdata

  which previously had been maintained for it's advantageous
download performance is now frozen,

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

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Torsten Dreyer]

Am 18.10.2011 19:45, schrieb Gijs de Rooy:
>
>  > Torsten wrote:
>  > git clone g...@gitorious.org:fg/fgdata-new data
>
> Make sure you don't forget .git. Use this:
>
> git clone g...@gitorious.org:fg/fgdata-new.git
touche - I'm getting too old for this ;-)

It works now, thanks!

Torsten

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Splitting FGdata (again, but now for real)

[ThorstenB]

Am 16.10.2011 16:14, schrieb Gijs de Rooy:
> For some reason, this splitting seems to takes forever on Windows (like
> 25 minutes for the 744),
> while Jorg managed to split the F-f16 in 90 seconds on Linux! Jorg will
> run a script (being Cedric's
> script, or some homemade combination) to split all the other aircraft.

Time also depends on aircraft size / commit count. Worst and longest 
operation is eventually filtering the repo to get rid of all the 
aircraft. With something as large as fgdata, it'll probably take many, 
many hours :). And it's 384 aircraft repos to be created. Counting 383? 
Well, don't forget the Antonov AN-2 
(https://www.gitorious.org/fg/ac-an2), which was split off months ago - 
it should also be added to the new project. And I'm curious whether 
gitorious.org is going to take such a huge number in a single project - 
I guess no one tried before ;).

When you're done, we should rename fgdata and keep it, at least for some 
time, until we're sure everyting is safe. Also, all branches are lost 
with the new repos, so it may be good to retain the "historic-fgdata", 
since it has the old release branches and tags. After renaming the old 
repo, we can create a fresh, new "fgdata".

cheers,
Thorsten

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] FlightGear launcher for snapshots/2.2 preview OSX

[HB-GRAL]

Hi all

I made a small launcher based on qt4 for FlightGear 2.2 on OSX. There is 
a FlightGear GIT version included for testing. The bundle contains 
todays master of simgear/flightgear and todays fgdata, reduced to a 
small and distributable selection of aircrafts. Requirement is OSX >= 
10.6 on a intel-based mac at the moment.

You can use the whole bundle also for your own devel versions or 
snapshots of flightgear/fgdata, just set the path to. There is also an 
edit for own fgfs commandline arguments.

Terrasync is included, also fgcom support, but you have to install fgcom 
separately (see my older mail here about fgcom for OSX).

I am looking forward for some feedback, bug reports and feature 
requests. Hope it is useful for some mac people around.

Cheers, Yves

The source is here http://gitorious.org/fgx (without binary and fgdata now)

Bundle with fgfs/fgdata included is here: 
http://fgx.sablonier.ch/fgx22pre3FULL.dmg





--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FPE while in-flight

[Roland Haeder]

Hi again,

forgot to add call parameters:

/opt/bin/fgfs --ai-scenario=vinson_demo --callsign=Quix0r
--multiplay=out,10,mpserver08.flightgear.org,5000
--multiplay=in,10,,5002 --config=$HOME.fgfs/cockpit-view.xml
--airport=EDDL --config=$HOMEfgfs/fgfs-base/fgdata/pyromaniac.xml
--control=joystick --aircraft=A380 --fg-scenery=$HOME.fgfs/kcdw:
$HOME.fgfs/gothenburg:$HOME.fgfs/scotland:$HOME.fgfs/Scenery:
$HOMEfgfs/fgfs-base/fgdata/Scenery-Extras:
$HOMEfgfs/fgfs-base/fgdata/Scenery-Airspace:
$HOMEfgfs/fgfs-base/fgdata/Scenery --log-level=warn --enable-clouds3d
--enable-horizon-effect --enable-real-weather-fetch --time-match-local
--enable-textures --disable-game-mode --enable-specular-highlight
--enable-fullscreen --enable-distance-attenuation
--enable-enhanced-lighting --disable-ai-models --fog-disable
--enable-anti-alias-hud --enable-save-on-exit --enable-splash-screen
--shading-smooth --time-match-local --enable-fpe

If you need that paste a little longer, I can upload it to my server.

Regards,
Roland


signature.asc
Description: This is a digitally signed message part
--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository

[Hal V. Engel]

On Friday, June 24, 2011 05:19:58 AM Francesco Angelo Brisa wrote:
> 2011/6/24 TDO_Brandano - 
> 
> >  Ok, before I get flamed to a crisp, let me explain what is my reasoning
> > 
> > behind this. Right now the fgdata repository is about 9 GB. [...]
> 
> I agree with Brandano, airplanes data is way too big for git, and the
> problem will only get worst with time.
> I would keep in git only a maximum of 3 aircrafts + UFO for scenery
> building.
> The rest should be kept away (I have no good idea right now). Can't the
> repository be hosted on the same server of the fgdata ?
> 
> Cheers
> Francesco

1. GIT is not the real issue as it is a powerful version control tool that can 
handle as much as any other tool out there.

2. The real issue is that fgdata is too big resulting in huge downloads and 
developers getting all kinds of stuff that they don't need.  That is most of 
the work in fgdata is aircraft work and most aircraft devs only touch one or 
two of the hundreds of aircraft in the repository.  

3. Regardless of what source code control system is used #2 is still an issue 
unless fgdata/Aircraft is somehow decomposed into seperate repositories for 
each aircraft.  

4. I think #3 applies to all aircraft including the UFO and any other "core" 
aircraft.  That is all aircraft should have code managed in the same way.

5. Having seperate aircraft repositories implies that there will be an "fgdata 
build" that can create a fully functional fgdata directory with some set of 
aircraft.  

5a. Perhaps this "build" can be configured by the user to use the aircraft 
status as a way to filter which aircraft are included in the "build" and 
perhaps there should be a small default set of aircraft that are always part 
of the "build".   

5b. For those following GIT who need to do regualr updates to fgdata to keep 
it in sync with fgfs GIT this will make that process faster and less bandwidth 
hungery.

6. Because we now have a functioning --fg-aircraft configuration using seperate 
repositories should be easy for aircraft devs to setup even if they are 
working on more than one aircraft.

7. Having seperate repositories for each aircraft would also facilitate 
managing who has commit and review privilages for each aircraft and allow for 
more fine grained security.   

8. There are a lot of details that need to be sorted out to make this work.

Hal

> 
> > Waiting for comments, flames and people asking "who is this guy?", yours
> > sincerely,
> > 
> > Alessandro Garosi (aka Brandano on IRC)
> > 
> > 
> > -
> > - All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity and more. Splunk takes this data
> > and makes sense of it. Business sense. IT sense. Common sense..
> > http://p.sf.net/sfu/splunk-d2d-c1
> > ___
> > Flightgear-devel mailing list
> > Flightgear-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
All the data continuously generated in your IT infrastructure contains a 
definitive record of customers, application performance, security 
threats, fraudulent activity and more. Splunk takes this data and makes 
sense of it. Business sense. IT sense. Common sense.. 
http://p.sf.net/sfu/splunk-d2d-c1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] fgdata trouble

[Christian Schmitt]

Thanks Thorsten for your clear words,
yes, it sucks to see people messing up the history, merging local branches 
and then pushing them to gitorious. I personally see another problem in the 
way changes that are merged appear in the history: The merge date is there, 
but the commits associated to it can be hidden somewhere down in the 
history. This is a very bad state when it comes to bughunting (bisecting).

Every fgdata contributor who creates complicated xml/shader files should be 
able to understand basic git workflow as well...

Chris



ThorstenB wrote:

> On 21 Sep 2012, at 13:03, Anders Gidenstam wrote:
>> The master branch of fgdata has become messed up. A number of commits
>> have become duplicated and some undone (they exist in the history but
>> their effect is gone from HEAD).
> 
> It has happened again, fgdata history is messed up. It looks as if my
> last commits (6d46fe7, f722671) were applied to fgdata multiple times
> now (duplicates are 818b92f and e7452f7). With gitk itself, I can't even
> see how where these originated (looks as if I had pushed them multiple
> times). Only the gitorious.org history shows that these were indeed not
> pushed by me:
> 
> 
https://www.gitorious.org/fg/fgdata/commit/818b92fa07a49c333f80ac21f483b33fd5e2b7c7
> 
> 
https://www.gitorious.org/fg/fgdata/commit/e7452f70358e67824e499294fd32d6d6f8d3dd93
> 
> Can we please make it a requirement that _local_ merge operations must
> not become visible on our public repository, so _everyone_ has to
> "rebase" before pushing anything?
> 
> The only merge/branch operations that should be visible in our public
> repo should be those that affect public branches (release branch
> creation/merges etc).
> 
> There's really no reason why other people should see that user XYZ has
> merged his local branch 1-15 times with gitorious, before pushing back.
> It only results in the git history becoming unreadable. And apparently
> it results in more issues.
> 
> If you compare simgear's or flightgear's history with fgdata's history,
> you'll see how nice and readable a git history can be - since obviously
> (almost) everyone pushing to sg/fg knows hows how to rebase.
> 
> Resolving merge operations locally, to reorder and cleanup the history
> is really simple - and only requires a few seconds. If you have
> uncommited changes in your local directory, you can temporarily stash
> them - so that "rebase" won't complain.
> 
> For fgdata:
> git stash
> git rebase origin/master
> git stash pop
> 
> (And for simgear/flightgear:
> git stash
> git rebase origin/next
> git stash pop
> )
> 
> It is also a good idea to check the git history (gitk) before pushing to
> gitorious: you can read and double check your own changes a final time -
> and also check the history for local merge or funny duplication issues.
> If you're having local Git trouble (like duplications), *please* ask
> before pushing to gitorious.
> 
> cheers,
> Thorsten
> 
> 
--
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html

--
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] use-custom-scenery-data

[HB-GRAL]

Am 09.06.11 11:41, schrieb Durk Talsma:
> Hi Alex,
>
> On 09 Jun 2011, at 11:21, Alex B. wrote:
>
>>
>> No. 1)
>> Durk wrote[1]: "[...]and the files that are still called "parking" are
>> the ones that I still need to rename / improve / verify." There are
>> still files called "parking" in the base package. Maybe someone will
>> rename / improve / verify them before the 2.4.0 release. I even do
>> volunteer for this job if I'd only know what to do and if there is no
>> nasal or C++ coding involved.
>>
>> find $fgdata/Scenery/ -name *parking*
>> $fgdata/Scenery/Airports/K/H/W/KHWD.parking.xml
>> $fgdata/Scenery/Airports/K/H/A/KHAF.parking.xml
>> $fgdata/Scenery/Airports/K/O/A/KOAK.parking.xml
>> $fgdata/Scenery/Airports/K/S/F/KSFO.parking.xml
>> $fgdata/Scenery/Airports/K/S/J/KSJC.parking.xml
>>
>>
> Basically, verifying the files would entail loading them into a recent 
> version of taxidraw, selecting the "verify groundnetwork option" and 
> correcting any errors indicated. Then they can be resaved. If you decide to 
> do this, please ensure to send a copy to the updated files to me, so I can 
> upload them to the terrasync repository.
>
> Cheers,
> durk
>

Hi Alex

I parsed (custom scenery terrasynced) groundnet and (default scenery) 
parking files in my qt flightgear launcher to get parking positions, and 
I also noticed that there are differences in the files.

When someone stops using terrasynced files for any reason, parking files 
will probably give "wrong" or "older positions", maybe also some 
positions are missing, also for AI Traffic (?).

If someone will check the differences I made diffs/patches to this 
parking/groundnet files and found following:

KHAF -> http://pastebin.com/CsqDmptB
KHWD -> http://pastebin.com/YSUULScj
KOAK -> http://pastebin.com/vf8WKJfP
KSFO -> http://pastebin.com/Q4jyJe4Q
KSJC -> http://pastebin.com/uBZaBbej

As long as I can see there are only a few updates in atc frequencies 
(!!? why are this freqs in parking/groundnet files?) and small changes 
in positions, looks like groundnet files are updated, parking not.

Cheers, Yves

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT and FGDATA

[Vivian Meazza]

Alan Teeder wrote


> > I am not seeing the slowdown.  I just ran a simple script that updates
> > simgear, flightgear source, and fgdata.  I would estimate that the "git
> > pull origin" run in fgdata took about 3 minutes.  This performance has
> > been typical for me.  I  ran System Monitor (F12) during the fgdata pull
> > and the data rate was between 96 and 100 KB/s and the memory usage was
> > constant.  I connect via Earthlink dsl.
> >
> > Dave P.
> 
> Dave
> 
> >From earlier posts I surmise that you have a 64bit Linux box.
> I have an old single processor XP box (limited to 1 GB memory by the
> motherboard) and a newer dual-core laptop. These run Xp and Vista
> respectively. Not in the same league as yours :-(
> 
> 
> My searching on the net suggests that the Windows version of Git is not as
> fast as the Linux original. The net result is that Git on Windows needs a
> higher spec processor than flightgear does when used with a large and
> frequently changing set of data such as fgdata.
> 
> During "pull origin" Git´s CPU usage goes to 100% (or 50% on the dual core
> box)  and Gits´s memory increases to over 100M, but there is negligible
> net
> usage.  I have let it run for 3 hours with no sign of any completion. My
> guess is that Windows Git is having trouble sorting out all the changes
> and
> updating its internal databases.
> 

Yes, I'm seeing this on a Core2Quad - all cores go to 100% and then nothing.
However, good old Git-bash shell will work from the command line. Not really
21st Century, but it will let you do most anything you want. This is not
inconsistent with Dave P observations, because I guess his script uses shell
commands stuff.

I think we might have predicted something like this happening when we could
only clone fgdata in the first place by downloading it in 2 sections. That's
another fine mess we have gotten ourselves into!

Never mind, we'll get it sorted (and perhaps shadows at the same time) :-)

Vivian



--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] fgdata trouble

[Alan Teeder]

What happened to the work that went into breaking up fgdata into manageable 
chunks?

New flightgear git users are faced with an initial download of about 10gb 
just to get started.

It seems to me that this current problem is another good reason to 
re-arrange fgdata.

So much work went into it last year, all to be scuppered by what seems to 
have been a unwillingness  on the part of a few individuals to agree on the 
implementation.

Alan

-Original Message- 
From: Tim Moore
Sent: Saturday, September 22, 2012 8:34 AM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] fgdata trouble

On Fri, Sep 21, 2012 at 11:51 PM, ThorstenB  wrote:
> On 21 Sep 2012, at 13:03, Anders Gidenstam wrote:
>> The master branch of fgdata has become messed up. A number of commits
...
> It has happened again, fgdata history is messed up. It looks as if my
> last commits (6d46fe7, f722671) were applied to fgdata multiple times
> now (duplicates are 818b92f and e7452f7). With gitk itself, I can't even
> see how where these originated (looks as if I had pushed them multiple
> times). Only the gitorious.org history shows that these were indeed not
> pushed by me:
>
> https://www.gitorious.org/fg/fgdata/commit/818b92fa07a49c333f80ac21f483b33fd5e2b7c7
>
> https://www.gitorious.org/fg/fgdata/commit/e7452f70358e67824e499294fd32d6d6f8d3dd93
>
> Can we please make it a requirement that _local_ merge operations must
> not become visible on our public repository, so _everyone_ has to
> "rebase" before pushing anything?
>
> The only merge/branch operations that should be visible in our public
> repo should be those that affect public branches (release branch
> creation/merges etc).
>
I haven't looked at this latest problem in detail, but you can do as
much damage rebasing as merging. I suspect the real problem here is
rampant cherry-picking. I happen to think merging, at least when
pushing local changes to the public tree, is a lot better than
rebasing, because then a given set of changes only appears in a single
commit in the repository.

> There's really no reason why other people should see that user XYZ has
> merged his local branch 1-15 times with gitorious, before pushing back.
> It only results in the git history becoming unreadable. And apparently
> it results in more issues.
Yes, pushing a branch that has numerous merges from master/next is
unpleasant. There are many pages on the Web describing git workflows
that avoid rebasing and keep a clean history.
>
> If you compare simgear's or flightgear's history with fgdata's history,
> you'll see how nice and readable a git history can be - since obviously
> (almost) everyone pushing to sg/fg knows hows how to rebase.
Except that I never rebase before pushing to sg/fg :) I should qualify
that: I do interactively rebase before pushing, often rearranging
commits and divying them up to make more sense. But I *never* rebase
onto a different head than the one on which I started the branch.
>
> Resolving merge operations locally, to reorder and cleanup the history
> is really simple - and only requires a few seconds. If you have
> uncommited changes in your local directory, you can temporarily stash
> them - so that "rebase" won't complain.
>
> For fgdata:
> git stash
> git rebase origin/master
> git stash pop
>
> (And for simgear/flightgear:
> git stash
> git rebase origin/next
> git stash pop
> )
>
> It is also a good idea to check the git history (gitk) before pushing to
> gitorious: you can read and double check your own changes a final time -
> and also check the history for local merge or funny duplication issues.
> If you're having local Git trouble (like duplications), *please* ask
> before pushing to gitorious.
Can't argue with that.
>
> cheers,
> Thorsten
>
> --
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html