George Patterson wrote:
> On 25 December 2011 22:39, Martin Spott wrote:
>> HB-GRAL wrote:
>>
>>> Yes, right, mutiple stations. FGCom server down, all radio stations down.
>>
>> One FGcom server up, all radio stations up :-)
>>
>
> Which doesn&#x
HB-GRAL wrote:
> Yes, right, mutiple stations. FGCom server down, all radio stations down.
One FGcom server up, all radio stations up :-)
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
HB-GRAL wrote:
> Can you point me to docs how to setup a fgcom server ? I didn?t find it
> at all, and it looks like FlightGear has only one FGCom server, one
> radio station at all.
One FGcom server != one radio station
Martin.
--
Unix _IS_ user friendly - it's just selective about
Pedro Morgan wrote:
> What the Sim missing at the moment is some real ATC...
We have OpenRadar,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
-
Peter,
Pedro Morgan wrote:
> Is there a way we can work towards a more "accessible" multiplayer
> enviroment for next year +
To be honest, it's a little bit difficult to understand that you're
trying to explain to us.
> And to do some of the Multiplayer tasks without FG.. as an install..
Why s
Ah, BTW,
thorsten.i.r...@jyu.fi wrote:
> I believe the intended spelling is 'GrassLand', [...]
No, it wasn't ;-)
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
--
thorsten.i.r...@jyu.fi wrote:
> And another materials.xml issue:
>
> materials.xml has the spelling 'Grassland' whereas materials-dds.xml knows
> both 'Grassland' and 'GrassLand'.
>
> I believe the intended spelling is 'GrassLand', at least the other
> spelling leads to problems with the newly c
Martin Spott wrote:
> I've been using "osm2pgsql" for years for importing The Planet Dump
> into PostGIS and so far I'm quite satisfied. After the bare import I'm
> using a custom script to separate the various road types into distinct
> tables/layers, so
Stuart Buchanan wrote:
> On Mon, Dec 19, 2011 at 10:07 AM, Martin Spott wrote:
>> Ron Jensen wrote:
>>
>>> I just noticed the c172p.xml (FDM) in FGData doesn't match the one in
>>> JSBSim.
>>
>> What's your conclusion ?
>
> Conclusio
Hi Peter,
Peter Sadrozinski wrote:
> Have you tried to triangulate the landclass in GRASS yet? I was wondering
> how well that works compared to triangleJRS.
I have to admit that I never did that myself.
At one of our meetings maybe more than two years ago Ralf presented to
me what later ended
Hi Peter,
what you're describing sounds familiar. Ralf and I had been observing
at least two characteristic types of failures:
1.) An airfield hole (or a road) cutting a landcover polygon into two
parts of which the (much) smaller one was left without centroid after
clipping.
2.) A centroid sitti
Ron Jensen wrote:
> I just noticed the c172p.xml (FDM) in FGData doesn't match the one in JSBSim.
What's your conclusion ?
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
-
Martin Spott wrote:
> Note that there are many, many different variants of the real one,
> therefore claims like "it climbs too fast" might be rather moot the
> smaller the deviation gets, because it depends much on the weight
> (which might depend a lot on the instal
Patrick Callahan wrote:
> What can be said about the flight dynamics of the C172P model?
> Is it accurate? If not, how could it be improved?
The response varies _much_ depending on whom you ask :-)
Personally I'm quite confident with FlightGear's flight dynamics, but
there's always room for imp
Hi Peter,
Flightgear-commitlogs wrote:
> It doesn't crash, but sometimes, polygons lose their material. I
> think fixing that
> should be easier than the endless massaging of data to keep good
> looking data.
According to my/our (Ralf's and mine) experience loosing the mater
Gijs de Rooy wrote:
> Next to that there are some typos/faults in current Git with respect to
> shader-properties, so it is possible
> that some shaders are accidentally still enabled. I'm preparing a commit that
> fixes quite some bugs, hope
> to push it today. But you can already test it via
HB-GRAL wrote:
> The coordinates comes from column base/reciprocal ends of runways,
is your definition supposed to be identical to "runway centerline
at threshold" ?
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
"Vivian Meazza" wrote:
> The other one, which used to be non-op, seems to have gained operational
> capability along the way.
You see, in order to avoid confusion, having just one operational
arrestor would have been the clever solution.
We're trying to simulate real-world, don't we ? Sure, we'
HB-GRAL wrote:
> And close to my nose I see here some mystic FAA data output:
[...]
> Is this something that could/should come to the scenery database somehow ?
Generally I'd say: Great ! but I'd feel best if I knew that these
positions really match the touchdown areas of 'our' runways. Ho
"Vivian Meazza" wrote:
> The ones I did in fgdata are BAK12.
Just for the record, the original BAK-12 was provided by David Culp:
http://scenemodels.flightgear.org/modeledit.php?id=918
We're having two models of a BAK-12 in the Base Package because some
people here are incapable to comprehend
Just a quick note from my end:
While Olivier mentioned only myself as a reviewer of Scenemodels
commits, I consider this new system not only as an aid to reduce the
overall workload for reviewers/committers but also as a tool which
later allows to un-tie the process of submitting object positions
Stuart Buchanan wrote:
> I currently maintain the c172p.
I still don't understand why Heiko was alienated from maintaining the
C172 model
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
Gijs de Rooy wrote:
> Stuart, now we're at it, could you please decrease the cockpit-status-rating
> of the
> C172P? It really is not complete and does not fit the five-stars category.
> For example,
> our current model even lacks something as a master switch! Nor does it have
> "photo-
> rea
Jari Häkkinen wrote:
> There are some files with the executable permission bit set in the git
> repo. To reset the file mode please apply the attached a patch to the
> getstart git repo.
Thanks, applied,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends a
Dan DeGraw wrote:
> I did a little tweaking to the multiplayer code to allow you to use a
> startup option "--ai-gliders-only" to, by default, load all other
> players as the default-model. I accomplish that by inserting some
> garbage directory in front of the model path, that way the model loadi
Hi Gene,
Gene Buckle wrote:
> One thing you guys are forgetting is that both apt.dat and nav.dat are
> updated regularly by Robin Peel, the "keeper" of those two files. I think
> changing them would probably bite you after a while.
Robin's v8.10 files are unmaintained since August 2008, v8.50
I'd do a cleanup in "fgdata/Models/Effects/" by removing the subdir
"Lights/" and its content in favor of "RedLight1.xml" and
"GreenLight6000.xml", updating any references if necessary.
Any serious objections ?
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about wh
Erik Hofman wrote:
> There already is, fgdata/Sounds
> If more than 4 aircraft use the same file I'd say put them there
> instead.
Coordinating aircraft development errm, teaching pigs how to
fly !? ;-)
Martin.
--
Unix _IS_ user friendly - it's just selective about who its frien
Hi Thorsten,
ThorstenB wrote:
> [...] We're going to branch off the 2.6
> release (fg/sg/fgdata) on January 17th. We could convert any remaining
> stereo sound files shortly before that, to make sure that FG2.6 doesn't
> mean a regression for many aircraft. I'm happy to run a batch job for
>
Hi Peter,
Peter Sadrozinski wrote:
> I think I've reached a good point to start applying changes to the
> terragear repo. I can either start issuing merge requests, or, given
> access, apply changes on a dev branch.
I'd say have a branch, send me your Gitorious account name, please.
> A couple
kreuzritter2000 wrote:
> When we're talking about MSFS and terrain i also want to mention, that
> their regular grid allowed them to use textures that allowed a seamless
> crossover on their borders. So with the right textures choosen, the
> textures matched on the borders.
Ah, well, but, as I un
Stuart Buchanan wrote:
> (For any third party reading this, Arnt's comments are not usually a
> reflection of the general view of the FG community, as a perusal of the
> mailing list will quickly show)
+1
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends ar
Stuart Buchanan wrote:
> I'm working on it right now...
Note, it's having sister-pages "Speyside" and "Western Isles",
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
--
Stuart Buchanan wrote:
> I will be treating myself to a small glass of Balvenie as a reward :)
Btw, while we're at it, I'm looking for a volunteer to retrieve the
coordinates from this website so we can add all the distilleries to our
Scenery - at least as shared objects:
http://www.dcs.ed.ac
Erik Hofman wrote:
> On Thu, 2011-11-24 at 10:39 +, Alan Teeder wrote:
>> error: unable to create file Aircraft/Tecnam-P92/Nasal/p9*2.nas
>> (Invalid argument)
>
> I've renamed it to p9X2.nas, I didn't see any reference to it anyhow.
After pulling your change I actually hat _both_ files sitt
HB-GRAL wrote:
> Thank you very much for providing this service ! These days I am working
> for a small publication for an organisation. Just found this image here
> to have in the publication:
> http://maptest.fgx.ch/screens/ksfo.png
Oh my, what a crappy Scenery, all the airport boundaries are
"J. Holden" wrote:
> It looks like there are a number of holes in the SRTM-1 data.
One-arcsec SRTM2 is well-known to be pretty 'dirty' and version2_1
doesn't make a big difference in this respect. In most cases you
should be better off using 3 arcsec, even for the U.S.
Cheers,
Martin.
-
Stuart Buchanan wrote:
> I don't think there is any particularly good reaon for the
> dependency, for either the trees or the clouds. I'm away at the
> moment but will look at uncoupling them later in the week.
Don't forget to pick up your virtual bottle of fine Whisky (note the
spelling) afterw
Gijs de Rooy wrote:
>> Martin wrote:
>> Well, having one where most of the available checkboxes are making just
>> a minor difference compared to the single, big "Material shaders"
>> switch isn't much better, I'd say ;-)
>
> Agree. But do note that 3D clouds is also disabled when disabling "Mat
Hi Gijs, thanks for elaborating the details !
Gijs de Rooy wrote:
> But then we might end up with a pretty large rendering dialog...
Well, having one where most of the available checkboxes are making just
a minor difference compared to the single, big "Material shaders"
switch isn't much better,
Martin Spott wrote:
> Because the list of overlay has been growing a lot, I'll re-organize
> some of them, [...]
Mostly done,
Martin.
--
Unix _IS_ user friendly - it's just selective about who
HB-GRAL wrote:
> We count 33 vertex shader, 31 fragment shaders, 2 geometry shaders and
> 117 effects files using this and that. This probably has a noticable
> impact.
Does anyone know how to have the random trees without all this ?
Cheers,
Martin.
--
Unix _IS_ user friendly -
ThorstenB wrote:
> I have added a new subsystem and dialog to monitor FG performance.
Oh my, what a mess, yet another attempt of improving things in a
structured way :-)
> The new GUI dialog is available in the menu: "Debug" => "Monitor system
> performance".
> Example: http://imageshack.us/ph
Hi, this message affects only for those who are having FlightGear
MapServer URL's bookmarked or stored otherwise.
Because the list of overlay has been growing a lot, I'll re-organize
some of them, for example by collapsing most of the OpenStreetMap line
features into a single one and doing the same
Erik Hofman wrote:
> Actually I meant the addition of curved taxiways [...]
Well, that's TerraGear and thus mostly unrelated to the release cycle
of SimGear/FlightGear, especially as long as the respective developers
consider their work as being too experimental even to put it into a
_branch_ of
Erik Hofman wrote:
> Well I've seen some pretty impressive shader and landclass geometry
> improvements [...]
Landclass geometry ? You mean texture coordinate size ?
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
---
Frederic Bouvier wrote:
> De "ThorstenB" :
>> I like the current timing (main testing phase in the end of
>> December/January and the release in February) a lot. I guess many of
>> us are busy with RL in the weeks before Xmas - with deadlines to be met,
>> both, RL-work and private ones :). Things
Jason Cox wrote:
> With GRASS how ever there is no doco and so it would take people such as
> myself a long time to come up to speed.
Nobody will force you to use a GRASS-based Scenery toolchain,
especially not if you're happy with the current one.
Cheers,
Martin.
--
Unix _IS_ user fri
Pedro Morgan wrote:
> Can we try and make final at 18th dec..
I don't think so, we're at minimum one month too late - _plus_ a
certain time span to let everybody commit their latest features before
the freeze.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who i
Erik Hofman wrote:
> On Sun, 2011-11-13 at 11:02 +0000, Martin Spott wrote:
>> Ah, well, I'm having mixed feelings about the shaders because they're
>> imposing a huge performance hit onto our bigger multi-monitor setup
>
> Did you try to lower the effects lev
César Espinoza wrote:
> "The entered e-mail address is already in use.
> Your IP 200.108.108.63 has been blocked because it is blacklisted. For
> details please see http://www.sorbs.net/lookup.shtml?200.108.108.63.";
Cool, last time it took me approx. two weeks to de-list a customers'
SMTP relay
Christian Schmitt wrote:
> So if you all agree, I can create a clipper/epsilon branch against master to
> get this tested first.
Yes, please, maybe even one for clipper and another with Maxime's
epsilon changes applied.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective
James Turner wrote:
> Looks very good to me - especially when it's combined with some of
> the shader / materials work that is coming!
Ah, well, I'm having mixed feelings about the shaders because they're
imposing a huge performance hit onto our bigger multi-monitor setup
Cheers,
Ma
Curtis Olson wrote:
> So this all sounds good (I think) except we now have to compute a point
> inside each material region. Easy, right? Well, except that all the
> published algorithms can tell you if a random point is inside a polygon or
> not, but they don't tell you how to manufacture a poi
Maxime Guillaud wrote:
> The only problem that prevents me from calling it final and generating custom
> scenery for
> all of Europe can be seen in the last screenshot:
> http://www.mguillaud.net/fg/scenery-gallery/fgfs-screen-008.png
I've seen a couple of these when preparing the terrain which
Peter Sadrozinski wrote:
> I think most of the work we are doing (alternate clipping library,
> 850 format) should be considered experimental, however. I'm pretty
> sure we want to keep the main branch concentrated on fixing problems
> with detailed landclass.
Sure, I didn't propose to put the e
HB-GRAL wrote:
> I just noticed that this small scenery bugs at KSFO never have been
> fixed since many years now (or did I miss something?).
Base Package or TerraSync - or both ? :-)
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
---
Chris Marr wrote:
> I'm using the build instructions here:
> http://wiki.flightgear.org/Building_FlightGear_-_Debian
If you happen to be on Debian/AMD64 stable, then you might consider
using the 3.0.1 packages available from here - they're a simple
backport by building the source packages for Sid
Hi Maxime and others,
Maxime Guillaud wrote:
> You can find my code here [...]
I'm just starting to recover from a couple of _really_ tight days
(including a nice PostgreSQL conference "PGConf.DE" where I gave a talk
about our geodata collection and in-database processing), therefore I'm
not yet
Flightgear-commitlogs wrote:
> commit 0905b4f36781c057b0c17b5af2c9ccfd72cf0fcd
> Author: Durk Talsma
> Date: Sat Nov 12 18:40:23 2011 +0100
>
>Fixing an age old bug. AIAircraft arriving on an airport never
> received a proper gateId, causing them to taxi to the end of the
> world and beyond
Christian Schmitt wrote:
> Can confirm the fix as well. It works all as expected. Waiting for your last
> feedback now, Martin, before preparing the merge.
I'm pretty certain the crash in 'fgfs-construct' is unrelated, just the
usual issue we already know. Therefore I'd vote to merge the CMake
Jon Stockill wrote:
> On 04/11/11 00:00, Martin Spott wrote:
>> Jon Stockill wrote:
>>
>>> Simgear doesn't seem to install to the correct directory on 64 bit
>>> systems any more - there doesn't seem to be any way to tell it to use
>>> /usr/li
James Turner wrote:
> This is fixed now, though I don't really understand how it ever
> worked - rawdem.c wasn't checking a particular return code nicely,
> now it does.
Thanks a lot, things are looking much better now ! I'll perform a few
more tests and will report back.
In the meantime we mana
"Alan Teeder" wrote:
> Is there a possibility of adding Lat-Long grid lines? It looks almost ready
> for deployment.
Yes.
> No doubt someone will come along again and say that FG can??t use Openstreet
> maps. ;-)
Nobody says FG can't use OSM, it always depends on what you're using,
how you're
Jon Stockill wrote:
> Simgear doesn't seem to install to the correct directory on 64 bit
> systems any more - there doesn't seem to be any way to tell it to use
> /usr/lib64 instead of /usr/lib
That's in "LIB_POSTFIX". Try:
# ~> cmake -D CMAKE_INSTALL_PREFIX=/usr -D LIB_POSTFIX=64 [...]
Che
Christian Schmitt wrote:
> Martin: Can you tell me under which OS this is happening? So I can try to
> reproduce it in a VM.
That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and
Glibc-2.11.2, if it matters,
Martin.
--
Unix _IS_ user friendly - it's just selective abo
James Turner wrote:
> On 2 Nov 2011, at 19:48, Martin Spott wrote:
>>> Fixed now, at least, it generated a ton of .dem files for me.
>>
>> Really ? And you're on simgear/next and terragear-cs/cmake-integration
>> without local changes ?
>
> With som
Michael Sgier wrote:
> Ok I did a fgdata clone:https://gitorious.org/~scrat/fg/scrats-fgdata
Why did you go through all the hassle of creating an isolated workspace
instead of cloning the repo directly at Gitorious ?
Martin.
--
Unix _IS_ user friendly - it's just selective about who it
James Turner wrote:
> On 2 Nov 2011, at 18:51, James Turner wrote:
>
>>> In normal operation, "raw2ascii" should almost immediately start
>>> writing lots of files to "${WORKDIR}/SRTM-30-ASCII/e020n90/", but with
>>> current simgear/terragear-cs I'm just getting an insane number of
>>> lines:
>>
Martin Spott wrote:
> Yes, "raw2ascii" doesn't work with both "simgear" and "terragear-cs"
> HEAD and therefore "demchop" is still untested. I'll provide a test
> case as soon as time permits - spare time is a bit tight these days.
O
Christian Schmitt wrote:
> Not only can I hgtchop, but also build scenery chunks again. So from my
> point of view the problems are solved. Are there any objections against
> pushing the changes to master?
Yes, "raw2ascii" doesn't work with both "simgear" and "terragear-cs"
HEAD and therefore "
Geoff McLane wrote:
> I guess I was a little unclear about other
> WMS servers... What I wanted to say was nothing
> I found offered any particular advantages over
> what the current Map application produces using
> current fgdata BTG files, and OpenGL rendering...
Well, the cause is pretty s
"J. Holden" wrote:
> The USA's land cover is in raster format, [...]
Is this NLCD you're digitizing ?
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
---
Martin Spott wrote:
> I'd just have to compile the Atlas imagery into a suitable format.
Just as a side note: I'll issue a virtual bonus for removal of the
requirement to have an (OpenGL-capable) $DISPLAY from Atlas' "Map"
utility ;-)
Cheers,
Martin.
--
Un
Christian Schmitt wrote:
> Jason Cox wrote:
>> I ran lsof on the PID and have found that it is still holding all SRTM2
>> arr and fit files open. This is the probable cause of the memory leak
>> that I am seeing.
> What confuses me a bit is you using SRTM-2 files. What is this and how does
> hgt
Hi Alex,
Alex Perry wrote:
> I don't know what you're getting at. If Atlas knows how to get map
> tiles from a URL family in addition to the usual disk file name
> family, that doesn't affect offline use.
Indeed. I was just thinking out loudly about how Joe Average might
recieve the requiremen
Hi John,
"J. Holden" wrote:
> http://www.stattosoftware.com/flightgear/ksfo_new.png
>
> Obviously needs some manual clean-up (bridge re-classification for
> instance), but hopefully this is the first step toward better default
> scenery.
It's probably not going to be the first one: Our current
Durk Talsma wrote:
> Ah, thanks for catching. Little type that wasn't caught in my
> generation script. Should be fixed now.
Well, "all flights cancelled" would be late-breaking ;-)
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
-
Hi Alex,
Alex Perry wrote:
> [...] What is
> preventing us from converting the whole Atlas project to WMS, and
> dropping the old nomenclature?
I'm just guessing: Backwards compatibility with those users who'd like
to use Atlas without being required to have a functional internet
uplink ? The
Flightgear-commitlogs wrote:
> commit ad39221c71d656887e3dbeac568bfc6b5d36029d
> Author: Durk Talsma
> Date: Sun Oct 30 21:21:19 2011 +0100
>
>New traffic for Qantas, [...]
All flights cancelled !? ;-)
Martin.
--
Unix _IS_ user friendly - it's just selective about who its frien
Geoff McLane wrote:
> As you may know the Atlas project already has
> a GetMap application, linked with CURL to
> to do the http requests... written by Fred back in 2004,
No, I didn't know. When I talked to Brian Schack about this topic, the
conversation somehow got lost (and I do feel guilty i
BARANGER Emmanuel wrote:
> With osgearth we could even create a specific server complete with cards
> containing information navigation (NAV, VOR, ILS etc. ..)
osgEarth is not the first choice of a tool for this sort of work. In
order to feed tools like Atlas or moving maps in general from a net
Jason Cox wrote:
> [...]--xdist=15 --ydist=35
[...]
> is it not appropriate to issue a build of such a large area?
Not really ;-)
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
James Turner wrote:
> Can you describe / give me a minimal test setup?
I'm really running out of ideas and my buget of testing time for today
(maybe this week) is exhausted. I've tested various pairings of
'simgear' and 'terragear-cs', unfortunately without getting a 'hgtchop'
creating subdirect
James Turner wrote:
> Can you describe / give me a minimal test setup?
Difficult, because 'hgtchop' doesn't work any more either, not even
with terragear-cs/master ;-)
Try this one for the preparational step - adapt from my setup:
DATADIR=${HOME}/archive/GIS/GISData/SRTM/version2_1/HGT/SRTM3
WO
Martin Spott wrote:
> Apparently directory path handling has been changed recently in a way
> which prevents 'terrafit' from recursively walking the given directory
> tree.
> This issue is with cmake-integration/CMake, cmake-integration/Autoconf
> but master/Autoconf is
Christian Schmitt wrote:
> [...] These changes are not yet in the master tree, but can be tested in the
> topics/cmake-integration branch. Please do so, if possible, so we can iron
> out any showstoppers.
Apparently directory path handling has been changed recently in a way
which prevents 'terr
George Patterson wrote:
> Btw, Berlios is closing on 31/12/2011 so grab what you need now. I am
> not sure if Mathias has moved the above project to another host.
I'm sure Mathias will speak about the details himself, but aside from
that I can confirm he's aware of the implications. In case of d
Heiko Schulz wrote:
> To my surprise they showed a picture of one of their simulators- and
> it does shows Flightgear! (obviously KSFO 28R)
Yup, quite a few serious research projects are using FlightGear for
visualization - but, as far as I can tell, none of them is using any of
FlightGear's int
I just added a comment to a merge request for "terragear-cs" on
Gitorious and I think this might be of general interest. Therefore I'm
posting the same comment as a followup to this thread:
- snip -
Increasing the ressource limits i
Jason Cox wrote:
> is our data for heights taken from the chopped up DEM/HGT files or is
> the terrafit files used?
Both. Array files are a mandatory requirement, terrafit output is for
optional enhancement - from a quick glance I guess the respective code
section should be this one:
http://m
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,
Curtis Olson wrote:
> We are committed to git, I'm not suggesting otherwise, but the entire binary
> history of the data tree is pushing 10Gb.
I'm not sure if we're talking about the same item, but the "bare"
repository of the entire 'fgdata' in its current state should be at
approx. 4 GByte or e
Jacob Burbach wrote:
> Seems like most people are just banging their heads against the wall
> trying to make a new system the same as the old, which is counter
> productive and unfortunate.
I wonder by which justification you pretend to speak for a group whose
common understanding you never bothe
Curtis Olson wrote:
> A super module sounds ideal if that's doable in git. Looking forward to it!
Gitorious will be pleased if everybody starts pulling everything from
scratch - and developers will be pleased by Gitorious' performance when
everybody starts pulling everything from scratch.
Previo
Cedric Sodhi wrote:
> On Wed, Oct 19, 2011 at 10:28:33AM +0300, thorsten.i.r...@jyu.fi wrote:
>> You seem to entertain the idea of a free lunch - get the goodies which
>> being part of the Flightgear project has to offer, but keeping the freedom
>> to do what you want. That may be a positive creat
Curtis Olson wrote:
> Anyone have any good ideas?
Yes, revert the dissection of 'fgdata' until a practical solution is in
place which doesn't require lots of people to waste extra time just to
achieve the previous state which simply works for them.
Spending some thoughts on how to compensate the
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 !
---
HB-GRAL wrote:
> There is so many "software" to do exactly this task. I could not imagine
> that our scenery is THAT important for this developement.
At least our Scenery led to significant improvements in the way GRASS7
deals with vector data ;-)
Cheers,
Martin.
--
Unix _IS_ user fr
ThorstenB,
ThorstenB wrote:
> Yes, true, we noticed that already. Hence we'll have to leave it as it
> is right now. A bit unfortunate, this would have really shrunk the
> archive significantly. But we may still be able to do that one day...
The two biggest chunks in Models/ are Weather/ (110
301 - 400 of 2338 matches
Mail list logo
