Am 10.12.11 07:52, schrieb Tuomas Kuosmanen:
Wouldn't it be useful to somehow flag the airport as
closed/restricted/whatever in the data, so that nav displays and gps/fms
units could show a different airfield symbol if desired for closed
airports? Does the data format support this?
There is
Am 11.12.11 01:10, schrieb James J. Brennan:
Sure they are marked in some charts as they might be useful in an
emergency, but essentially they are not much different from a large
parking lot or a wide road.
One came in pretty handy a few years ago when a guy ran out of gas.
Something
Am 08.12.11 13:36, schrieb HB-GRAL:
Hi all
Hi again
About marking closed airports in apt.dat:
- marking the name with [X] might be closer to charts I guess and
most airports marked as closed in apt.dat comes with the x
- removing x and marking with (closed) at end of name is possible
.)
Origin in apt.dat is a) in apt.dat, but my script eats it up. So better
no change for this case ?
Cheers, Yves
Am 08.12.11 13:36, schrieb HB-GRAL:
Hi all
I am recently trying to update apt.dat airport names (in all flightgear
relevant data versions, means original xplane 8.10/8.50
Hi Fatima
Just found something with your output, just in case you still get the
same errors with the ogr plugin.
http://forum.openscenegraph.org/viewtopic.php?t=2953view=previous
Cheers, Yves
Am 01.12.11 15:53, schrieb Iervolino Fatima:
Hi Thorsten,
I've rebuilt all successfully. But I'm
Am 30.11.11 21:13, schrieb ThorstenB:
Am 30.11.2011 15:40, schrieb Iervolino Fatima:
I get systematically the same error:
1Compilation en cours...
1ReaderWriterOGR.cpp
1..\..\..\..\src\osgPlugins\ogr\ReaderWriterOGR.cpp(41) : error C2146:
erreur de syntaxe : absence de ';' avant
Hi Adrian
I think quality textures like yours goes directly to the main repo ? On
the other hand I heared there is probably central scenery repo coming
up (a separate repository and/or database). Maybe also for developing
textures and to store origins or base material ?
Green as I am I
Am 22.11.11 15:06, schrieb Adrian Musceac:
Hi Yves,
The issue here is that some of these textures are really large, and thus have
the potential to limit performance for users with lower-end machines.
Thus, I'm interested in guidelines/policies regarding texturing the terrain,
what sizes are
Am 22.11.11 20:44, schrieb Adrian Musceac:
The problem with small textures is that patterns on them become very visible
at high altitudes. On the other hand, good textures with no visible repeating
features are quite hard to obtain.
Adrian, you might have a look what the crop shader does
Am 22.11.11 20:50, schrieb Emilian Huminiuc:
- on-disk size depends on texture size, amount of colour variation in the
texture and compression method.
(a 4096x4096px texture can be as big as 10 to 30 MB if compressed as png, or
~20MB if compressed as dxt5 .dds, or ~10MB if compressed as dxt1
Am 20.11.11 12:55, schrieb Anders Gidenstam:
On Sun, 20 Nov 2011, ThorstenB wrote:
Since some effects may be aircraft specific it might be useful to make the
advanced dialog dynamic - one way would be to add a checkbox for each
*-effect property found in /sim/rendering/shaders/ .
Hi Gijs
I would be very happy with a reflect checkbox/property once. Just to
remember issue #295 (stalled, why?), this one is still broken with my
ati on osx, osg trunk. It is not broken at all, but it still produce
this renderbin draw errors filling my fgfs log to a huge file running
Am 21.11.11 22:08, schrieb Arnt Karlsen:
On Mon, 21 Nov 2011 14:55:34 +0100, HB-GRAL wrote in message
4eca5856.6060...@sablonier.ch:
Hi Gijs
I would be very happy with a reflect checkbox/property once. Just
to remember issue #295 (stalled, why?), this one is still broken with
my ati on osx
Hi Thorsten
Thank you very much. Is it also possible to interpret OpenGL/GPU load
somehow this way ?
Cheers, Yves
Am 19.11.11 17:22, schrieb ThorstenB:
I have added a new subsystem and dialog to monitor FG performance. It's
replacing/improving the original code which was only capable of
Am 19.11.11 21:43, schrieb James Turner:
On 19 Nov 2011, at 19:54, HB-GRAL wrote:
Thank you very much. Is it also possible to interpret OpenGL/GPU load
somehow this way ?
OSG already has this - exposed via the Debug menu in FG.
(Well, not in much detail about the GPU - normally that kind
Am 16.11.11 10:58, schrieb Martin Spott:
I was annoyed by the fact that the simple act of just enabling
Material shaders in the Rendering options has a noticeable effect
on the rendering performance without_any_ of the other features in the
entire dialogue box enabled.
We count 33 vertex
Hi all
I updated positions.txt (fgcom data) with recent 8.10 apt.dat data for
use with fgcom. And I also prepared the same for 8.50 data for the
future. For testing you can replace this file with current positions.txt
shipped with fgcom. It contains all frequencies available in table
atcfreq
Oh, just noticed that this is an issue of fgx and fgfs process start
parameter, and absolutely not fgfs related, sorry for the noise.
Cheers, Yves
Am 14.11.11 01:02, schrieb HB-GRAL:
Hi all
I bundled a new FGx launcher today for OSX with current trunk and OSG
3.1.0, and after some tests I
Hi all
I bundled a new FGx launcher today for OSX with current trunk and OSG
3.1.0, and after some tests I noticed that fgcom does not get any input
anymore from fgfs. When I start fgcom manually with i.e. -f910.0 I do
not have any problem, but from fgfs it gets only 0. freqs
runnning.
Am 12.11.11 11:05, schrieb Frederic Bouvier:
See : http://frbouvi.free.fr/flightsim/fgrun-rating-system.png
And what about this one ?
http://frbouvi.free.fr/flightsim/fgrun-rating-system-star-en.png
-Fred
--
Am 10.11.11 12:14, schrieb HB-GRAL:
Assuming the fix table should contain VFR waypoints mainly, another
question might be if the fix table can be filtered (only for the map)
into waypoints containing only VPXYZ-Point-Naming and others
containing numbers ? Is this a bad idea (for the map
Am 12.11.11 19:35, schrieb Frederic Bouvier:
Hi Yves,
Am 12.11.11 11:05, schrieb Frederic Bouvier:
See : http://frbouvi.free.fr/flightsim/fgrun-rating-system.png
And what about this one ?
http://frbouvi.free.fr/flightsim/fgrun-rating-system-star-en.png
Hi Fred
Looking to the bars and
Am 12.11.11 20:00, schrieb Frederic Bouvier:
Am 12.11.11 19:35, schrieb Frederic Bouvier:
Hi Yves,
Am 12.11.11 11:05, schrieb Frederic Bouvier:
See : http://frbouvi.free.fr/flightsim/fgrun-rating-system.png
And what about this one ?
Hi Scenery
I just noticed that this small scenery bugs at KSFO never have been
fixed since many years now (or did I miss something?). When you show me
how I can help to fix this, I will really send a merge request, and I
guess this is not critical ! But should be solved once ;-)
osgDB ac3d
Am 13.11.11 00:12, schrieb Curtis Olson:
So now it would be interesting if fgrun could be used by end users to rate
the aircraft in the different categories and then fgrun would pull the
ratings from some server that tracks all this. :-)
Curt.
Oh yes, I will immediately set up a new
Am 10.11.11 09:50, schrieb James Turner:
On 10 Nov 2011, at 07:36, HB-GRAL wrote:
- Approach Fix
- Intermediate Fix
- Final Fix
- MAPT
- Step down
- Fly-by
- Fly-over
- Co-located
- Speed limit (?)
Is there any possibility to classify the bare 8.50 fix database
somehow, i.e. by name
Hi all
I tried to add 8.50 .dat version fixes to my map (map.fgx.ch)
yesterday. I see that the database contains the name of the fix/waypoint
and coordinates and no further cols. Wouldn’t some classification be
useful, i.e.
- Approach Fix
- Intermediate Fix
- Final Fix
- MAPT
- Step down
-
Am 07.11.11 11:12, schrieb Anders Gidenstam:
On Sun, 6 Nov 2011, HB-GRAL wrote:
But I didn?t spoke out what Gary, Jacob and Anders write here. This is
exactly what I meant and it was no vote against every improvement of the
old shaders where I contributed too. Me and myself would be very
Hi all
I just noticed today that the textures folder in scenery growed from 50
MB to ~200 MB. But I don’t see that many new textures ? I read once here
that the benefit from getting DDS is also we get smaller file sizes for
the textures. But now I see textures like crop (and cropA) DDS files
Am 06.11.11 13:50, schrieb Heiko Schulz:
Quality compared with other compressed texture-formats like .png is btw. much
higher.
Hi Heiko
What I am thinking about at the moment is: Where are the GPL origins of
the new textures ? In the textures folder too ? And btw. there have been
only 4
Am 06.11.11 15:22, schrieb Jacob Burbach:
On Sun, Nov 6, 2011 at 9:10 AM, HB-GRALflightg...@sablonier.ch wrote:
Just a technical question: I know it is not a big deal to convert new
textures to .dds format, but when I want to start to work on textures
should I convert back to another format
Am 06.11.11 16:32, schrieb Heiko Schulz:
And btw. there have been
only 4 or 5 replacements/additions for covers
...
Thanks, I will do so. And where do I find the lossless origins now in
the repo ? Do the origins co-exist in the repo, as png, or as GIMP files ?
Ouch!!
Ouch ?
1.) the
Am 06.11.11 17:56, schrieb Heiko Schulz:
Hello,
Ouch ?
This was regarding about your statement about the 4-5replacements/additionals
and maybe I'm wrong, but I think I can read something between your lines.
You are not happy with the conversion to .dds-files, right, though you didn't
Am 05.11.11 03:27, schrieb Roland Häder:
On Sat, 2011-11-05 at 01:31 +0100, HB-GRAL wrote:
Hi James
I successfully built simgear/flightgear today with cmake 2.8.4 and OSX
10.6.8. There have been some small changes I added to CMakeLists for
sg/fg: SET(CMAKE_CXX_FLAGS -arch i386) and SET
Am 05.11.11 17:13, schrieb James Turner:
On 5 Nov 2011, at 11:25, HB-GRAL wrote:
Maybe how to set this flags for OSX should go to the readme once. I
think some OSX users will end up with linking errors because simgear
compiles well with x86_64, but then you run into a lot of problems
trying
Am 05.11.11 20:25, schrieb HB-GRAL:
Am 05.11.11 17:13, schrieb James Turner:
On 5 Nov 2011, at 11:25, HB-GRAL wrote:
Maybe how to set this flags for OSX should go to the readme once. I
think some OSX users will end up with linking errors because simgear
compiles well with x86_64
Am 05.11.11 20:46, schrieb HB-GRAL:
Am 05.11.11 20:25, schrieb HB-GRAL:
Am 05.11.11 17:13, schrieb James Turner:
On 5 Nov 2011, at 11:25, HB-GRAL wrote:
Maybe how to set this flags for OSX should go to the readme once. I
think some OSX users will end up with linking errors because simgear
Am 04.11.11 08:35, schrieb Tuomas Kuosmanen:
Hey folks.. How about using something like maps.cloudmade.com to create a
custom styled openstreetmap tileset for a moving map? Alternatively a
mapnik style could be created. There was a style for aviation paper chart
in progress in openstreetmap
Am 03.11.11 20:46, schrieb Alan Teeder:
I have now copied everything to https://gitorious.org/fg-ajt, which should
speed things up.
Alan
Hi Alan
Thanks for uploading this tiles to gitorious. Can you say something
about the box (in coords) this tiles cover exactly ? I am going to run
Am 04.11.11 10:06, schrieb HB-GRAL:
Am 03.11.11 20:46, schrieb Alan Teeder:
I have now copied everything to https://gitorious.org/fg-ajt, which should
speed things up.
Alan
Hi Alan
Thanks for uploading this tiles to gitorious. Can you say something
about the box (in coords) this tiles
Hi James
I successfully built simgear/flightgear today with cmake 2.8.4 and OSX
10.6.8. There have been some small changes I added to CMakeLists for
sg/fg: SET(CMAKE_CXX_FLAGS -arch i386) and SET(CMAKE_C_FLAGS -arch
i386). I am sure there is a better way to set this flags with cmake.
Many
Hi all
I see so many good and nice additions for FlightGear, why not follow
former polls I’ve seen here and organize a small award in december,
somthing like best add-on development for FlightGear ?
Possibility to give two awards, one from a public i.e. as a vote in the
forum and another as
Hi
maybe it is also worth to have a look to (local) capabilities of
- mapnik2
- kde marble
Cheers, Yves
Am 31.10.11 06:35, schrieb Alex Perry:
On Sun, Oct 30, 2011 at 3:20 PM, Martin Spottmartin.sp...@mgras.net wrote:
Alex Perry wrote:
[...] What is
preventing us from converting the whole
Am 30.10.11 19:42, schrieb Geoff McLane:
FORMAT=image/jpegSRS=EPSG:4326
Hi Geoff
Just one little thing here, in case someone is working on this: I
suggest not to use image/jpeg for rendering, I guess it is better to use
image/png for quality maps.
Cheers, Yves
Am 27.10.11 10:24, schrieb James Turner:
'we' (the infamous FlightGear we) should probably write a wiki page of
aircraft-contributor-etiquette, so we have grounds to revoke people's access
if they break the rules. Though just about the only rules I'm aware of :
keep it GPL;
Am 25.10.11 19:09, schrieb syd adams:
I dont personally see any advantage myself, I'd have to vote no.Sorry Yves.
--
The demand for IT networking professionals continues to grow, and the
demand for specialized
Hi Core (and the rest of the entire organism of course)
Why not splitting up the Aircraft folder into hangars as collection of
aircrafts as plug-ins, collection of big teams or small but heavy
industries ?
--- fgdata
|
Aircraft
||
|
mirror and it is fetched every 30 mins. or so).
Cheers, Yves
Am 23.10.11 00:24, schrieb HB-GRAL:
Hi all
I just set up a mirror of your (not ours, I will get it) gitorious
repos with git/gitolite/cgit. It is easy to explore the repositories
with cgit, just have a look. There is no use
Hi all
I just set up a mirror of your (not ours, I will get it) gitorious
repos with git/gitolite/cgit. It is easy to explore the repositories
with cgit, just have a look. There is no use for this, but it is fun (at
least for me).
http://git.fgx.ch/
Cheers, Yves
Hi Scenery
Here I provide converted and clipped Alaska elevation data (2arc
seconds) from NED USGS, for testing and developing purposes. The
original data is distributed from NED in ArcGIS format, I needed to
convert to USGSDEM format to create a new relief for my map. Maybe this
will be
Am 15.10.11 10:53, schrieb Martin Spott:
I think the only solution is to make GPC obsolete - either by replacing
GPC by something different but functional equivalent or simply (TM ;-)
by avoiding any polygon clipping in 'fgfs-construct' overall.
Martin.
Hi Martin
Are there any
Hi James
Thank you very much (and Martin of course) for diving into. I am just
curious how you go to replace GPC.
Cheers, Yves
Am 15.10.11 17:20, schrieb James Turner:
On 15 Oct 2011, at 15:22, HB-GRAL wrote:
I think the only solution is to make GPC obsolete - either by replacing
GPC
Am 15.10.11 22:41, schrieb Christopher Baines:
I know of another project who's main git repository contains a script,
that manages the other git repositories, this allows them to split the
gigs of data they have in to more sensible chunks, without having to
pull every repository individually.
Am 16.10.11 00:30, schrieb Martin Spott:
HB-GRAL wrote:
Am 15.10.11 10:53, schrieb Martin Spott:
I think the only solution is to make GPC obsolete - either by replacing
GPC by something different but functional equivalent or simply (TM ;-)
by avoiding any polygon clipping in 'fgfs-construct
the dem's into
TerraGear tile sizes. There are different terrain formats so you might need
to adapt the code to read a different format as well. This part sounds like
it should be pretty straightforward if you have clear docs for the input
format.
On Thu, Oct 6, 2011 at 6:40 PM, HB-GRAL wrote
When someone wants to run experiments with this data, you can find
some test data in .dem format here:
http://maptest.fgx.ch/public/2arc-alaska-dem/n70w140.zip
Thanks a lot, Yves
Am 07.10.11 12:07, schrieb HB-GRAL:
I am asking because I am currently working on Alaska elevation data
Hi all
Can terragear handle 2 arc second elevation data ? I read only about 1
arc and 3 arc data for the terragear toolchain.
Cheers, Yves
--
All the data continuously generated in your IT infrastructure contains a
Am 06.10.11 11:33, schrieb Vivian Meazza:
We already adjust the greyness of the sea to reflect the overcast
value. (It would also be nice if the visible weather in Global matched the
description a bit better: we make the sea grey when it's overcast, but the
sky is still mostly blue).
This
Am 21.09.11 07:59, schrieb Alex Perry:
12. ... who is missing from the list?
I just decided to start with russian airspace, because of this one here:
http://premier.gov.ru/eng/events/news/9704/
Cheers, Yves
--
All
Am 25.09.11 09:36, schrieb Erik Hofman:
On Sat, 2011-09-24 at 15:29 +0200, Frederic Bouvier wrote:
It would be nice if Tim Moore could also fix the fog/skydome
misalignment he introduced.
It's a bit harsh as the previous code was also buggy
It wasn't meant to be harsh but the old code
Am 21.09.11 21:43, schrieb John Denker:
3) I suspect that doing reprojections on the the fly only
works for vector data. I tried it with raster data,
expecting to see either a resulting image or an error
message, but saw neither. Is there something I'm missing?
It works also for
Am 21.09.11 21:43, schrieb John Denker:
4) When defining a colormap, there does not appear to be
any way of controlling transparency on a level-by-level
basis. Am I overlooking something, or is this an actual
limitation?
Maybe I miss something but you can control transparency for
Hi there
Is there anyone out doing some mapping/scenery improvements on Alaska ?
I decided to make Alaska as a center for testing some new sources and
experimental scenery improvements. Does anyone know about a FlightGear
Alaska initiative in the past ? Beside of contribution to scenery or map
Hi all
To improve our map resources with further data I started an experiment
with free available airspace data. Actually this is far from being a
good map and finished design, it is just a start to implement
(unofficial!) airspace information:
http://maptest.fgx.ch/navaid.html
I need
Am 16.09.11 07:28, schrieb J. Holden:
For the USA, there is an interesting website chronicling some of these
airports: http://www.airfields-freeman.com/
Cheers
John
Hi John
I provide a ESRI Shapefile on my server of the airports of
ourairports.com database
Hi
Here you can download two ESRI shapefiles where I provide some
differences between NDBs in xplane data (8.50) and ourairports.com data.
NDBs in xplane data, but not in ourairports (585 NDBs):
http://maptest.fgx.ch/data/ndbmissingourairports.zip
NDBs in ourairports data, but not in xplane
Hi
Here you find a ESRI Shapefile with ~3700 helipads missing* in 8.50
xplane data (and maybe in current fg data), located mainly in United States:
http://maptest.fgx.ch/data/helipad.zip
Maybe someone finds this useful.
Cheers, Yves
Am 15.09.11 18:12, schrieb Martin Spott:
HB-GRAL wrote:
I see now also some differences between OSM and our apt.dat [...]
Note that OSM might be aiming at a different target, they're not
necessarily building a database which meets the specific requirements
in (simulated) aviation.
Cheers
Am 14.09.11 08:58, schrieb thorsten.i.r...@jyu.fi:
LaTeX is not a word processor, it is a professional typesetting tool.
I see all the reasons to keep the docs in LaTex (like keeping the
process efficient at the moment), but this sentence here about
professional tools is probably not that
Am 12.09.11 09:56, schrieb Alan Teeder:
Google maps are notoriously incorrect on co-ordinates. Even their own road
map overlay does not align perfectly with the scenery. You can check the
accuracy yourself if you have a GPS receiver and visit a set of easily
identifiable points like road
Am 13.09.11 10:46, schrieb thorsten.i.r...@jyu.fi:
LaTeX is not a word processor, it is a professional typesetting tool.
I see all the reasons to keep the docs in LaTex (like keeping the
process efficient at the moment), but this sentence here about
professional tools is probably not that
Am 11.09.11 03:20, schrieb Curtis Olson:
Asking a cartographer where is it? is just about as difficult a question
as asking an astronomer what time is it?
Curt.
Hi Curt
These are very good questions. I will ask some cartographers and
astronomers.
Cheers, Yves
Am 12.09.11 00:39, schrieb Martin Spott:
HB-GRAL wrote:
Exactly, that's a default in Robin's collection.
Hi Martin
Yes, sorry, you answered me this one some months before and I just
forgot about. It is part of the collection and this probably makes sense.
Cheers, Yves
Am 09.09.11 22:56, schrieb Frederic Bouvier:
I hope you all remember that there is already a 8.50 parser inside fg and
code to display airports in the MFD (with Bezier curves).
Regards,
-Fred
Does this parser handle both types, 8.10 and 8.50 format ? As I
understand 8.50 is only
Am 10.09.11 14:47, schrieb Christian Schmitt:
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
Am 10.09.11 21:56, schrieb Viktor Radnai:
Hi all,
If you are looking for airports with extreme runway slope for testing,
may I suggest Lukla, Nepal (VNLK). If that one comes out looking right,
I'd say you've got the code sorted :)
Cheers,
Vik
Lukla is just boring ;-) Other suggestions ?
Hi all
Unfortunately I just run into another problem with my map.
This is what I see on my currently generated map using 8.10 taxiway data
and 8.50 runway data (this is no reference and a crude mixup of course,
I apologize in adnvance):
http://maptest.fgx.ch/screens/mapping.png
But now, I
Am 24.08.11 17:51, schrieb Gijs de Rooy:
Btw, is the taxiway layer not yet implemented, or is that another broken
thing?
The taxiways were broken because I first needed a way to handle the
current 810 taxiway patchwork shapetry ...
Am 09.09.11 19:33, schrieb Curtis Olson:
In addition, there is a fairly sophisticated (and I think cool) step where
we fit a natural curved surface across the airport elevation and used the
curved surface instead of raw SRTM points. This eliminates the noise in
the raw data and gives the
Am 04.09.11 08:05, schrieb Durk Talsma:
Hi All,
In the past, we've seen a large number of projects that were initiated for
FlightGear; Atlas, fgrun, the terragear toolchain, and taxidraw. Many of
these program have undergone substantial development, many contributors have
come and gone,
Am 04.09.11 15:01, schrieb Gijs de Rooy:
Why not use Xplane's WED? Appears to be open-source (didn't check the license
though) and works with the 850 format...
Hi Gijs
I use QGis because with this one I edit current shape database directly,
without any conversion of anything. And most of the
Am 04.09.11 16:01, schrieb Christian Schmitt:
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
Am 04.09.11 17:11, schrieb Geoff McLane:
On Sun, 2011-09-04 at 15:01 +0200, Gijs de Rooy wrote:
[snip]
Brings me to another question, are we allowed to use Robin's latest
apt.dat, once we can handle the new format? Looks like that day isn't
too far away anymore
Am 01.09.11 10:24, schrieb Vivian Meazza:
Spelling the title correctly in the English version would be a huge
improvement.
Vivian
Hi Jörg
I hope Vivians English style is not the only feedback you get about your
work here. Your contribution is welcome, at lest for me, and maybe
others can
Hi all
I created a new experimental mapnik mapserver. It is based on
mapnik/ogcserver/tilecache/postgis/postgres. For testing purposes I
pushed 850 aeronautical data from Robin Peel into the database and
render some example queries. The database knows the whole world, the
example is
Hi Navs
I see with release/2.4.0 of fgdata there comes fix.dat, nav.dat and
awy.dat and others from a data cycle 2009.12 by Robin Peel. Do we update
this files to the current available data cycle, with the release ?
Cheers, Yves
Am 09.08.11 09:59, schrieb TDO_Brandano -:
Well, if you know how to write a simple program you could try accessing and
setting the properties through the telnet protocol with a wrapper
application, and communicate with that one through the serial port. As far as
I know the telnet protocol
Hi all
I announced a new beta release for testing in the forum today. This OSX
testing version comes with built-in OSG 3.0.1 and a preview of current
sg/fg/fgdata branch release/2.4.0. Windows and Debian/other version
will follow soon (meantime you can pull master tag 2.4.0b4 and build FGx
Am 29.07.11 12:15, schrieb Durk Talsma:
Hi,
On 29 Jul 2011, at 02:54, HB-GRAL wrote:
Hi Geos
Can someone explain me why we use
lat=N37 42.807
lon=W122 12.963
in parking.xml and groundnet.xml
This is mainly for historic reasons. I started out using an example ground
Am 29.07.11 15:18, schrieb HB-GRAL:
Am 29.07.11 12:15, schrieb Durk Talsma:
Hi,
On 29 Jul 2011, at 02:54, HB-GRAL wrote:
Hi Geos
Can someone explain me why we use
lat=N37 42.807
lon=W122 12.963
in parking.xml and groundnet.xml
This is mainly for historic reasons. I
Hi Geos
Can someone explain me why we use
lat=N37 42.807
lon=W122 12.963
in parking.xml and groundnet.xml
and not lat/lon formats like we use it for runways and it is used in
apt.dat and other data files ?
Thanks, Yves
Am 25.06.11 17:59, schrieb Jari Häkkinen:
Otherworldcomputing.com has two options; ATI Radeon HD 5670/512MB
(USD180) and ATI Radeon HD 5750/1GB (USD400). 400 is a lot, will the
cheaper 512MB card make a noticeable difference? And, opening an iMac
isn't for the faint-hearted.
Jari
Hi Jari
Am 24.06.11 12:55, schrieb Erik Hofman:
On Fri, 2011-06-24 at 10:48 +, TDO_Brandano - wrote:
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.
It has been proposed before and I believe it's the way to go.
Hi all
For upcoming debugging weeks: Please note that issue #294 and #335 are
still valid here with OSX 10.6, ATI 5750, OSG2.9.7. I still get
Warning: detected OpenGL error 'invalid operation' at after
RenderBin::draw(..)
with every plane (i.e. 737-100) where reflect shaders are active.
I
Arghh, yes, I am talking about issue #295 and not #294, sorry for that.
-Yves
Am 23.06.11 14:17, schrieb HB-GRAL:
Hi all
For upcoming debugging weeks: Please note that issue #294 and #335 are
still valid here with OSX 10.6, ATI 5750, OSG2.9.7. I still get
Warning: detected OpenGL error
Hi all
On http:// gitorious.org/fgx I tagged now a FGx version 2.3.0pre as a
preview which (should) work for Debian, Windows and OSX. FGx is a
small FlightGear-qt-gui-launcher project. For OSX it is a bit more
(because it is a app bundle with built-in OSG libs and all FlightGear
binaries).
Am 13.06.11 19:36, schrieb Gene Buckle:
I've got this sneaking suspicion that 90% of the problems here are caused
by two people, separated by a common language translating engine. :)
g.
Hm, I guess you can say 100 %, at least on my side. Just found to
buckle sideways in a tranlating
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
Am 08.06.11 07:43, schrieb Michael Sgier:
why not simply change the fgfs licence once and for all? Android is not all
GPL anymore...we could do the very same.-
Why not throwing all the sources to trash and tell people the project
does not exist anymore ? :-)
No licence change has to be
Am 05.06.11 23:37, schrieb HB-GRAL:
Hi all
I am trying to to write fgfs stderr output to a file. This is no problem
when I use redirection like logifle.log in a shell of course, but -
unfortunately - this can not be passed as argument with qt by
startDetached process, which I use with fgx
101 - 200 of 330 matches
Mail list logo
