Hi guys,
As some of you might already know, we are working on improving the
scenery of Germany. Right now we are 3 people and I want to announce the
first preview of our work. It is currently only Frankfurt and its
Airport, but you can expect more to come in the future. I would be happy
to
till busch wrote:
hi christian,
sorry. that was my fault -- skimming instead of reading.
the scenery looks very nice to me. i think i miss a building with a
pyramid-shaped roof: messeturm?. (though my memory may not be the best, since
i was in frankfurt only twice).
cheers,
-till
till busch wrote:
hi,
would you mind adding a .tar.gz or a zipfile for easier download?
thanks,
-till
Hi,
as the whole thing is still in alpha or at least beta state, I want to
wait until it is more mature.
You can download it just as simple with
svn co
Hi Gabor,
first of all thank you for this very useful feedback.
I have noticed only one minor issue so far with the buildings of Terminal
2DE and 1C. When you load AI traffic data and ground map for EDDF in FG you
will see airplanes parking at wrong positions (behind the buildings of
Gabor Toth wrote:
Hi Chris,
extract the attached tarball into your data directory. You will also need
the appropritate AI aircraft (LH 737, LH 747, LH A320 LH A333). They are
available on Durk's site:
http://www.xs4all.nl/~dtalsma/flightgear.html
Regards,
Gabor
WOW! Thank you.
Hi everybody. The problem is mostly solved. The update is already in
SVN. I'm still working on making the remaining gates more accurate.
Cheers,
Chris
Gabor Toth wrote:
Hi Chris,
Let me express my appreciate to your wodwerful work. As I fly very often to
EDDF (in FG and IRL as well),
Heiko Schulz wrote:
Hi,
as long we havn't the discussed feature - where will
we able to download this Traffic-files?
There are some in CVS, but I sometimes heard, that
people did their own - would be grat if anyone can
profit from.
Cheers
HHS
I can offer to use my SVN for this.
Hello,
here is a short update:
Today I went to EDDF to take some photos of as many buildings and things
as possible, to be able to better create textures. Some of the results
can already be seen in SVN. However, I have one problem: There is
reconstruction going on on gate c/d and they built a
Hi Gabor,
This problem can come from two sources, the parking positions can be
defined
wrong, or the position or scale of the buildings can be wrong. Or both. :)
Now with more and more parts of the terminals being added, I encounter
more errors with the aircraft positions again (the
Hi,
I created some ebuilds for the CVS/SVN versions of FG, simgear andd OSG.
It works as an overlay and can be downloaded via:
svn co http://ilovelinux.de/svn/fgfs-gentoo;
It runs on two machines here right now, without problems, so I tought I
make them publically available.
Cheers,
Chris
Heiko Schulz wrote:
Hi,
I had a look too on the airport, and it looks great.
With AI-Traffic it looks real nice and realistic!
But I noticed that the groundnetwork not match to the
new Scenery 1.0.0 - that could maybe the problem.
Cheers
HHS
Thank you.
Yes, the ground network
Hi,
I just corrected the building positions once more and checked everything
with Google Earth. The parking positions are ok for our current
buildings. However, as I already wrote, there are some changes in
reality to make room for the A380. These new gates are spread across the
Terminals and
Hone more question: Is there a way to set maximum sizes for aircraft
that are allowed on a particular parking position? That would solve the
current problem of a 747 parking on at Gate B on a position not suitable
for that size.
Chris
Heiko Schulz wrote:
Yes, have a lok into the wiki:
http://wiki.flightgear.org/flightgear_wiki/index.php?title=Interactive_Traffic
Thanks for this hint. As soon as I get the NEW_GUI branch of Taxidraw
finally working here, I will maybe take a look there. But I'm still
modelling EDDF and it
Cleber Santz wrote:
Hi,
I solve the problem with plib (removed v1.84 already instaled), but
now i`m getting segmentation fault when run flightgear.
I think the problem is with data (fg can`t find models) but i make
checkout with the lastest data. I get 2 different dump, first
Christian Schmitt wrote:
Hello,
here is a short update:
Today I went to EDDF to take some photos of as many buildings and things
as possible, to be able to better create textures. Some of the results
can already be seen in SVN. However, I have one problem: There is
reconstruction going
James Sleeman wrote:
Am I the only one getting segfaults on a full compile of the latest HEAD
or is it just not working at the moment. Full update and compile of
everything, SimGear, OSG, Plib1.8.5, flightgear with --enable-osgviewer,
and data all up to date. Segfaults as soon as it tries to
Tobias Ramforth wrote:
Hi!
Everytime. I'll try rolling back to an older OSG when I get a chance.
Are you sure you recompiled every single lib using up-to-date sources
(CVS/SVN)?
I encountered a segfault, as well, but I forgot to recompile simgear.
Double check the compilation order,
Hey Durk,
Ralf just pointed me to you being the expert on AI/ATC and stuff like
that, which is IMHO one of the most important things for a good user
experience. :-)
As you might know we are currently doing a lot of work on EDDF. One of
the things I am doing right now is redesigning the
Durk Talsma wrote:
We are moving towards a more sophisticated runway exit strategy: Last year at
LinuxTag, Thomas Foerster and I discussed the idea of adding a performance
database that could be used to determine stopping distances, and I'm
currently working on adding support for runway
Melchior FRANZ wrote:
And according to a past agreement, this means that everyone should
from now on expect commits that require OSG 2.4 -- to add new
features, and to remove old workarounds.
Allright. I'll update the overlay :-)
Cheers
Chris
Markus Zojer wrote:
Hi all!
This issue still exists. The YASim FDM places the datum of the aircraft
at the end of the runway as startup position, which means that all
aircraft with datum=nose start behind the runway. Maybe we should use
the CG of the aircraft as reference point or
Holger Wirtz wrote:
Hi,
last week Flightgear was represented at Linuxtag 2008 in Berlin,
Germany. The TV station 3sat made some small trailers about Linux and
OpenSource projects. I made an mpeg2 stream which shows some projects on
this fair. At the end you can see some seconds of
Frederic Bouvier wrote:
Migrating from CVS to SVN would already be a very good thing IMO
-Fred
Sure enough. But if we take a migration into consideration, we sould
probably go the GIT route. Although I'm not too experienced with git
when it comes to committing things to it, from the git
Martin Spott wrote:
The FlightGear project has been notoriously behind about getting
people's source code contributions into CVS - for years. We all know
the story, it's been the same for years already, no need to repeat it
here.
So, in order not to loose the respective contributions over
Martin Spott wrote:
I was persuaded to mention that GIT allows you to wrap single steps of
your private development into independent commits to your local
repository, even if you don't have any network access while sitting at
the beach on a remote island
Once you're back to a place
Melchior FRANZ wrote:
* Melchior FRANZ -- 8/26/2008 3:03 PM:
But it would make me a bit nervous if an aircraft developer commits
several pointless updates of 5MB sound files. GIT can't compress that.
We'd collect the whole pile on our disks. How much would disk space
requirements grow each
Thomas wrote:
Thanks for that review. I'm still wary of the auto line term
conversion and would probably favor disabling it.
I'm more concerned about the 2 GB repo size limit listed in the Known
issues in the release notes. I don't think that will work for FG. Am
I correct in assuming
Stefan C. Müller wrote:
That's of course the safest choise for binary files. But it would
certainly mess up the text files.
While most windows tools can read LF, they all write CRLF by default,
some even to automatic conversion (like VC). We would end up having
files of both types (and
Hi everybody,
I recently started flying the Concorde intensively. There seems to be a
problem with the VL (VOR lock) autopilot. It sould follow a radial
towards/from a VOR, which it does, but it is not steering towards the
radial fast enough. The angle towards the radial is too small. This
Heiko Schulz wrote:
The last errors I had were:
-Bank-Angle-Callouts with real zero-angle after lift off or shortly above rwy
while landing.
- the callouts 50 40 30 20 10 could be never heard at all- even
with a very low sink rate
Low-Terrain-warning on a corrct ILS-glidepath
Durk Talsma wrote:
While I'm at it. :-)
With each release we include a selection of representative aircraft that
highlight FlightGear's capabilities. Inclusion criteria include:
Completeness,
variability across categories, realism, suitability for demo flights (think
of
aerotowing,
Hi,
I'm currently working on improving my Gentoo overlay for FG and added a live
version of fgrun to it.
There is a problem to compile it with --as-needed enabled as LDFLAGS.
During configure it already prints:
checking for gl_start in -lfltk_gl... no
which leads to a compile error later on:
Hi,
to make sure the anonymous original author is ok with the changes, I want to
announce here a merge request concerning the Concorde and ask for a
review/testing and a merge.
http://gitorious.org/fg/fgdata/merge_requests/15
Cheers,
Chris
Erik Hofman wrote:
I'm not sure, it needs time to look after some things. For one it should
be made possible for the shader to adjust the fog color located
under /rendering/fog but at this time values written to it will be
overwritten by the current code.
Erik
I can only agee with
Durk Talsma wrote:
Hi All,
As part of visualizing the AI ground networks from
within FlightGear, I've
been trying to find out whether there is a simple way
of drawing them
using a few OSG commands. As a start, for each of the
segments, I have a
start and end position in latitude /
Hello,
i have recently created many bigger scenery chunks with Corine Landcover and
OSM line data. Yesterday I wanted to do the same for all of the UK and
Ireland. Then I encountered some problems:
I encountered unknown runway surface errors, caused by some strange
heliport runways (see EGTG).
Martin Spott wrote:
After that genapts segfaulted during EGKK processing [...]
Did you use the 'public' apt.dat file from MapServer ?
Yes, indeed. I hope i'll be able to really get down to the problem today. I
still have no exact clue what caused it, although I recompiled with several
Martin Spott wrote:
http://mapserver.flightgear.org/Heliport.pl
Well, I'd rather get it right in genapts and I'm sure it's not too difficult
to accomplish.
Chris
--
Benefiting from Server Virtualization: Beyond
Christian Schmitt wrote:
After that genapts segfaulted during EGKK processing and right until now I
have still not much of a clue what exactly is going on. I thought it was a
problem with compiling TG against SG and not SG-CS (all from GIT). That
showed to be wrong. Next guess
Martin Spott wrote:
-#define __FLT_EVAL_METHOD__ 0
+#define __FLT_EVAL_METHOD__ 2
I think a simple -O2 should be permitted. Does it still fail with
setting just this single option ?
The O2 flag was set for all tries but it's not the problem here. The problem
are certain -march options.
Arnt Karlsen wrote:
..who's code, F|S|TG, or GCC? Which gcc version(s) did you use here?
Where the problem lies in the code I don't know. But it would be SG or TG.
My GCC version is 4.4.5, OS is Gentoo.
Debian has updated gcc-4.4 and gcc-4.6 yesterday and today, may
be updating gcc-4.5 now
Martin Spott wrote:
Well, to be more precise, it's been optimization for an incompatible
platfom ;-)
The Core2 has a slightly different instruction set from the Pentium
III, thus, if I were you, I'd let the 'native' compiler choose the
right platform optimization for you - as long as you
Curtis Olson wrote:
GIS on a global scale is a really really hard thing. There are tremendous
challenges in terms of data set sizes, processing time, numerical
representations, manipulating and crunching data, etc. Terrorgear is a
clever play on words, but any one who is ready to dive in
Csaba Halász wrote:
It is certainly good advice to optimize for the correct processor, but
using unsupported instructions typically result in a SIGILL not a
SIGSEGV.
It would help to see the actual disassembly around the fault and
machine register contents. It smells like alignment problem.
Csaba Halász wrote:
Info registers, and something like x/10i $eip (or $rip on 64 bit)
Here you go (still on Atom), Phenom this evening.
(gdb) info registers
eax0x0 0
ecx0xb7e67380 -1209633920
edx0x814aab0135572144
ebx
Christian Schmitt wrote:
Here you go (still on Atom), Phenom this evening.
Phenom:
(gdb) bt
#0 0x77bd4504 in merge_left (p=0x7c4f00, q=0x0, list=0x7c4f30) at
gpc.c:785
#1 0x77bd6861 in gpc_polygon_clip (op=GPC_UNION, subj=0x747fb0,
clip=0x770120, result=0x74edc0) at gpc.c
Curtis Olson wrote:
Right, as said before, you crashed inside the gpc code. Have you tried
regenerating this airport using the --nudge option (increasing the value
in small increments until you find a value that allows the airport to be
successfully built.)
Regards,
Curt.
Curt, it's
David Glowsky wrote:
Hi developers,
I have a new computer, installed FG on it and have a problem with the
graphics.
The problem (beside missing runway lights) is that surfaces generated
by a shader will flicker. This applies to terrain and aircraft
Moin David,
while I have no solution
Csaba Halász wrote:
Hm, ok, that doesn't seem to be SSE related, it's just your everyday
NULL pointer.
Have to check source code to see how that can happen.
Did you look into this already?
Would be a good start to fix this (if the problem is not IN the gpc lib).
Chris
Pascal J. Bourguignon wrote:
Papillon81's git repo is not available:
Please note that the link in the Newsletter only leads to the repo overview
on gitorious where you can see the clone URL right on top of the page. Use
this one and all should be fine :)
Chris
Vivian Meazza wrote:
The main problem is that the taxiway textures expose the workaround that
we use because we don't (yet) have curved taxiways. The concrete colour
does not blend with the old texture, which is still used for aprons etc.,
and the edge and centre lines also serve to
Geoff McLane wrote:
It certainly works better for me ;=)) And removes
another reason why fgfs-construct can abort
without apparent reason!
Hi,
you mean segfaults with no apparent reason? I experience them under Linux
when building huge scenery chunks and if your patch improves the situation,
Geoff, I applied both of your patches, see here:
https://gitorious.org/papillon81/terragear-cs
Until now I had no crashes or negative effects on the resulting scenery.
However, there IS a problem, unrelated to your patches, for which I hope to
get some help.
I create large chunks of scenery
Geoff McLane wrote:
It is certainly _NOT_ 'normal' behavior, and
historically (I assume Curt ;=)) implemented some
draconian 'rlimit' - setrlimit(RLIMIT_CPU,timeout),
to abort after a period of time, which is just
NOT available in my WIN32 environment, to avoid
such a 'forever' loop...
Hi,
Geoff McLane wrote:
Thanks. It is good to know that the -
Default=x, where x = 0-2 is 'normal', but
Chris reported that it was still running after
6 hours, or more... and still unable to exactly
find where this is output, in the code...
You won't be able to find Default in the sources as
Durk Talsma wrote:
I'm explicitly deleting all the Triangle and Edge objects. This has
improved performance a lot I'm still not able to process the entire
Eurasian continent in one pass, after this fix, the total number of
.fit files that can be created on my linux box has gone up from
Curtis Olson wrote:
Thanks Jon!
I've added this info to the flightgear.org web site.
If anyone else is working on packages for other linux distributions (or
knows of updates for other distributions) please post here or let me know
directly.
I'm maintaining the Gentoo packages for our
HB-GRAL wrote:
Personally I don’t know if there is a roadmap for taxidraw anymore. You
can edit airport data with tools like Qgis directly and with much more
comfort. It’s sad, but I think we dont need it anymore.
Well, you can import apt.dat data into QGIS via GDAL. But be aware that this
Durk Talsma wrote:
I've imported the complete revision history from CVS. At this stage, I
haven't really made a desision about whether I should try to keep the CVS
and gitorious projects synchronized, or whether we should abandon the CVS
repository altogether.
I don't see why you should take
Martin Spott wrote:
Well, why did this happen ? As far as I can tell no patch submission was
unheard.
Well, there are some patches in my TG tree that I'm using here and that
might be worth considering:
https://gitorious.org/papillon81/terragear-cs/commits/master
Am I right that the
James Turner wrote:
If you regularly pull+build 'next', please try a cmake based build, and
report any issues you encounter - CMake should work 'out of the box' on
Mac (Makefiles or XCode), Linux (32- and 64- bit) and Windows
(VisualStudio 2008 and 2010 - mingw and cygwin may need some
Curtis Olson wrote:
I won't say this is perfect in all areas ... some areas have stray data
points or noise in the terrain data that confuses things. There's always
a chance of a mismatch between airport location terrain location so that
we
are trying to put the airport on not quite the
Christian Schmitt wrote:
I have used CMake in the Gentoo packages pretty much from the start, but
right now I'm experiencing some problems: all is good as long as I have
libsvn support enabled in SG and FG. When I disable it in SG and want to
recompile FG afterwards (also disabled, of course
Hi there,
i just want to announce that I added support for the 850 apt.dat runways to
genapts. This work is thought as a compliment to the currently ongoing
development towards curved taxiways.
The current state is that genapts reads runways and creates them
accordingly.
Features:
-different
Christian Schmitt wrote:
Hi there,
i just want to announce that I added support for the 850 apt.dat runways
to genapts. This work is thought as a compliment to the currently ongoing
development towards curved taxiways.
The current state is that genapts reads runways and creates them
James Turner wrote:
Okay, but the relevant source file (sg_binobj) appears to contain both the
read *and* write code paths - which is really what I was asking - is the
write logic in sg_binobj.cxx the one terragear uses, or 'something else'?
James
Please be aware that TG uses SG-CS
Martin Spott wrote:
We're not yet there. On a first test earlier today, 'genapts' ended in
a segfault with the recent changes but I ran out of time, thus I
have not yet verified if the source change in 'simgear' really was the
culprit,
Confirmed here. And I thought first it was the
Martin Spott wrote:
We're not yet there. On a first test earlier today, 'genapts' ended in
a segfault with the recent changes but I ran out of time, thus I
have not yet verified if the source change in 'simgear' really was the
culprit,
Confirmed here. And I thought first it was the
Hi there,
maybe you have noticed some exceptionally high activity in recent days/weeks
on the Terragear repo. Well, there is one particular reason for it: It now
supports the cmake build system and, as of today, does no longer depend on
plib. These changes are not yet in the master tree, but
Geoff McLane wrote:
An error something like -
'do not know how to make main.c from main.o'
which I did NOT understand... seems reversed!
And why 'main.c', since the Makefile.am shows
only -
raw2ascii_SOURCES = main.cxx rawdem.c rawdem.h
There is no main.c here???
Hi,
this is caused
James Turner wrote:
A fair suggestion! I originally combined them because it was easier not to
worry about PLIB when creating the CMake files, but I wasn't expecting the
slightly-complex changes to de-PLIB the file handling code.
Let me see how hard it would be, to un-pick the changes.
Jason Cox wrote:
is it not appropriate to issue a build of such a large area?
should I use smaller chunks?
should terragear not be releasing the memory after building a tile?
Generally speaking, sometimes it works, sometimes it doesn't. And yes, it
should free unused memory after finishing a
Hi Jason,
I just tried to reproduce this issue here. Generating some scenery around
LOWI with 850 airport layouts, I only see always two SRTM files open: the
arr.gz and fit.gz for the tile that is currently built. So no problems here.
What confuses me a bit is you using SRTM-2 files. What is
Jason Cox wrote:
I would try a larger area, say 1x1 deg or larger and then and then you
will see the list grow to include tiles that are no longer needed.
I created a 2x3 degree area. No problems. What terragear-cs version do you
use and against which simgear do you compile it?
Will now
James Turner wrote:
I've pushed a fix to Simgear, updated the tests, and now I can run hgtchop
happily with latest simgear and terragear.
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
James Turner wrote:
With some local changes to Simgear/next, but I am 'fairly sure' they don't
relate to path/file/string handling. (Some changes in the SGOceanTile
handling)
I just tested this as well (without your fix) and it works here too. Even
when using Martin's pathnames.
Martin Spott wrote:
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,
I guess it matters, because I get exactly
Martin Spott wrote:
That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and
Glibc-2.11.2, if it matters,
Ok, I observed the following: compiling the raw2ascii as Release leads to
the error (on Debian). When compiling as Debug it works here.
Chris
Hi,
for those of you who are interested in some nice EHLE flyins can download the
custom scenery for NL with apt.dat 850 airports and OSM line data here:
https://gitorious.org/papillon81/flightgear-terrain
Have fun!
Chris
Martin Spott wrote:
Thanks a lot, things are looking much better now ! I'll perform a few
more tests and will report back.
Can confirm the fix as well. It works all as expected. Waiting for your last
feedback now, Martin, before preparing the merge.
In the meantime we managed to
Martin Spott wrote:
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
branch - just in case, we'd fix the remaining issues in master.
Done. If someone could remove the cmake branches, that'd be nice. :)
Hi,
Martin Spott wrote:
Thus, if you'd be willing to put your stuff into a branch at the main
repo, please go ahead - call us if you don't have write access.
I don't feel too good about adding even more branches directly into the main
TG repo. The reason is this: In the process of the 850
James Turner wrote:
Okay, this all sounds like good news indeed. Martin, Chris, Peter - I
think the steps need to be as follows - get a branch of terragear with the
clipper changes, and probably the epsilon changes Maxime describes
(because I've always worried, they were only needed due to
Hi,
yes, the 850 genapts supports the new approach lights. In fact, even the 850
version did in theory, but the file format did not.
The relevant code starts here:
https://gitorious.org/~papillon81/fg/terragear850/blobs/tg850/src/Airports/GenAirports/lights.cxx#line2635
Please ignore the
Christian Schmitt wrote:
Hi,
[...] In fact, even the
850 version did in theory, but the file format did not.
I mean 810, of course :)
Chris
--
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding
Stefan Gofferje wrote:
I think, we should seriously do something about this kind of stuff before
the MP world becomes a popular place for spammers, like e.g. have the MP
servers filter URLs out from the MP chat...
No, I do not agree. But for exactly this purpose we have the ignore
Martin Spott wrote:
Any volunteer(s) ? Proper representation of ground network nodes as
PostGIS (actually OGC) geometry data type preferred.
Apparently you don't want any 850 centerlines as a base for this, which
would be easy as gdal imports 850 data directly into Postgis, as you surely
flightg...@sablonier.ch wrote:
[...] I really wish we
could build some kind of temporary Scenery Team and discuss ideas.
My proposal is to meet at IRC on day the next weeks to start
organizing, or to open a temporary group or list. (Sorry, i do not
like the forum for such).
A scenery team
Hello,
here is the log of the meeting we held today as a first measure to formalize
future scenery development processes.
I deleted any mail adresses for privacy reasons.
Cheers
Chris
[17:26:58] MartinSpott I'm just interested in the log, thus if you prefer
to chat on 'your' server, then I'm
HB-GRAL wrote:
Now I am deeply offended. Did you ever have a closer look to FGx
launcher? It has exactly all this already prepared for you and this
project is open to any contribution.
I can understand you. And Curt, openlayers is by far a new thing. Not only
is it used in FGx (a nice
Stuart Buchanan wrote:
Given that we have 400+ aircraft that need to be updated, I think we
also need clear documentation (on the wiki?) describing the steps you
outline above, and in particular how to register the transparent
surfaces. That probably needs to be in place before the code goes
Curtis Olson wrote:
I have a local branch I've created here for some experimentation. When
ever I do a git pull from the gitorious repository, I do that in the
next/master branches. Then I switch to my local branch and type git
merge next (or master) to make my local branch up to date with
Gijs de Rooy wrote:
Looks like OGR-decode is broken (in the Windows builds at least) since
some time. I still don't completely understand the difference between OGR
and Shape, both seem to deliver the same results... Maybe someone else can
explain this?
ogr-decode uses gdal to process the
Hi,
the next meeting is planned for Monday, 26.3. at 16:00 UTC or 4
PM UTC.
Don't forget about the DST starting tonight in many countries :)
Hope to see many of you.
Chris
--
This SF email is sponsosred by:
Try
Tested under Gentoo with a Radeon HD 4670 and the fglrx driver: Works.
Render previews show up and the overall performance is nice.
I also ran a short test with the opensource radeon driver. There, the GLSL
version 1.3 was too much for it. I got a picture however.
Can't wait to see the render
flightg...@sablonier.ch wrote:
Hi Crhis, Torsten
What is really needed at the moment is someone starting to verify if some
changes to our apt.dat from the past have to come to recent apt.dat
shipped with FlightGear. Martin Spott prepared an updated apt.dat on the
mapserver, but the changes
Hi Yves,
flightg...@sablonier.ch wrote:
update in general? Why is it possible to update apt. and nav.dat in xplane
every months without (?) inconsistencies and not for FlightGear? Is there
something that could be changed in the concept of scenery and data
distribution for FlightGear?
Did
ThorstenB wrote:
But to be honest, it neither works with central terrasync scenery. We
could never push any updates (such as introducing terrasync scenery with
the new EDDF runway) without immediately breaking consistency with all
previously released FG versions (= their base packages). And
ThorstenB wrote:
But to be honest, it neither works with central terrasync scenery. We
could never push any updates (such as introducing terrasync scenery with
the new EDDF runway) without immediately breaking consistency with all
previously released FG versions (= their base packages).
We
1 - 100 of 116 matches
Mail list logo