On 08/05/2013 01:38 AM, Михаил Сойтанен wrote:
In nav.dat file VORs have slave variation. As
I understand, slave variation of VOR depends on magnetic variation at he
location. Does Flightgear use this slave variation, or it computes magnetic
variation on the fly?
Do we need to track magnetic
On 08/05/2013 03:45 AM, Михаил Сойтанен wrote:
I will send data about Russian VOR's to Robin, because
I have found, that variations are outdated.
That's good ... but it would be even better to figure out
how to get /systematic/ updates from reliable sources, now
and in the future. Is there
On 08/09/2012 07:45 AM, Curtis Olson wrote:
It looks like every time you rebase you have to reapply the same set of
patches over top the target branch.
Not true in general. I've never had a problem like that.
So even if I figure out a way through
it once, I'll have to repeat the same
Here's another fun way of mapping airspace: You can get sectional
charts in the form of .tif files from:
http://www.aeronav.faa.gov/index.asp?xml=aeronav/applications/VFR/chartlist_sect
You can then read them into QGIS ... and then overlay them with
whatever other information you want,
On 09/20/2011 07:08 PM, J. Holden wrote:
This is somewhat off-topic to FlightGear, so I apologize - but I
respond to John Denker: Having looked over what you are trying to do,
I strongly recommend using QGIS with the GRASS plugin.
Very rarely do I use any of GRASS' built-in visualization
On 09/19/2011 04:07 PM, HB-GRAL wrote:
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:
On 09/16/2011 04:47 AM, HB-GRAL wrote:
I provide a ESRI Shapefile on my server of the airports of
ourairports.com database
http://maptest.fgx.ch/data/ourairports.zip
There is a column type, and some airports have value closed. All
this data is in public domain, if someone wants to play
On 09/15/2011 05:15 PM, Martin Fenelon wrote:
I like to think that the positional errors of many (most non US?)
aerodromes are due to mistakes made when changing from one datum to
another.
Well, that's not what I think, based on looking at
the data.
The very first non-US example I looked
On 06/19/2011 06:46 AM, Jon S. Berndt wrote:
Maybe I've gone wrong somewhere here, but something similar might work.
Also, in situations like a flat spin or tail slide this probably falls
apart!
Let's postpone discussion of exotic flight conditions such as flat
spins and tail slides. There
On 03/03/2011 02:16 PM, cas...@mminternet.com wrote:
What are the coordinate conventions used for eye position offsets in 2.0?
standard right-hand rule or something else? Messing with the camera
offsets and not getting the results expected. OTOH, the documentation on
the subject is VERY old
On 02/10/2011 08:15 AM, Geoff McLane wrote:
Also, it does not happen EVERY time, in each of 3
machines, 3 OSes... but when I get the situation, it seems
very repeatable...
Is there any chance this depends on having a _tailwind_
or something like that?
Crosswinds and tailwinds can cause some
It's spelled ATI
On 01/27/2011 08:01 PM, Csaba Halász wrote:
I am now running the shiny new 11.1 fglrx driver on my integrated HD4200.
The 737-100 has some silly landing lights, but other than that, it looks
normal.
I just how upgraded to the 11-1 fglrx driver.
Still no runway lights.
I
On 01/25/2011 12:14 PM, Curtis Olson wrote:
How about having carriers do a terrain height check and follow the polygon
curvature of the FlightGear world?
Call it a feature.
The real ocean has swells. They make carrier flight operations
considerably more interesting.
On 01/20/2011 07:14 PM, Ryan M wrote:
For the past week I have been working on improved airport taxiway and
grass textures. They've gotten positive feedback on the forums but Gijs
suggested I post about them on the core mailing list for a fair
discussion.
Here are some screenshots of the
Do we know how X-Plane itself deals with the runway polygons?
The very existence of such things in the apt.dat file suggests
that some sort of solution is possible.
Perhaps some experimenting with a X-Plane and a hacked-up copy
of apt.dat would tell the tale.
On 01/16/2011 01:25 PM, Barry Fawthrop wrote:
There was a news article on Magnetic North Change
and How KTPA had to change from 90 to 80
Are these changes being effected into FlightGear ???
No.
FG is still using airport data that hasn't been updated since 2008.
More than a few things
On 01/16/2011 02:23 PM, Martin Spott wrote:
John Denker wrote:
FG is still using airport data that hasn't been updated since 2008.
Depends on your particular definition of FG. To be precise, the file
at:
http://mapserver.flightgear.org/apt.dat.gz [1]
contains 213 airfield
On 01/10/2011 08:26 AM, Curtis Olson wrote:
often, important tall objects
have a known absolute height ... like a radio tower in an FAA database. For
these objects it would be better to keep them at a fixed absolute height
rather than float them up or down with different revisions of the
On 01/04/2011 10:20 AM, Curtis Olson wrote:
I'm in a situation now where I have local
mods that git diff does not report and I'm not sure how to deal with that.
How can I find the differences between my local repository and the master
... especially those changes that I haven't committed
On 01/04/2011 05:51 PM, Dave L wrote:
I've reverted to the previous behaviour for that property, which means that
inches are used globally by default, and if the user sets that property then
millibars are used everywhere except US and Canada. I realise that that
means that the incorrect
I just pushed one more commit to
http://gitorious.org/~jsd/fg/sport-model/commits/navaid-repairs
This provides IMHO a pleasing combination of simplicity, versatility,
consistency, and verisimilitude.
The main new feature is to allow the active runway to be chosen to
have a crosswind or
I just now pushed a couple more ATIS upgrades to
http://gitorious.org/~jsd/fg/sport-model/commits/atis
One of them will, alas, require rebuilding the voice snippet data.
http://www.av8n.com/festival/
Mostly this is to improve the internationalization.
On 01/02/2011 09:21 AM, Stuart Buchanan wrote:
- Romeo is being pronounced Romo. Might be a typo in the transcript?
It's not a typo, just lousy pronunciation by the synthesizer (festival).
Note that if you are worried about typos, you can check for yourself
by looking at the property tree
Hi --
On 01/02/2011 06:37 PM, you wrote:
Can I just clarify whether you are happy to have your scripts committed to
flightgear/utils in addition to being available from your website?
Yes, happy.
Public domain, not GPL.
If so, I'll add them ASAP.
Thanks!
Comment #8 on issue 110 by timoore33: Pick animation do not hilight
transparent objects any more
http://code.google.com/p/flightgear-bugs/issues/detail?id=110
fixed with simgear c934b47f2e94fcefb719b9b6186abc4fd8562670
Wow. That helps a lot.
On 12/27/2010 03:59 PM, Dave L wrote:
The ATIS/AWOS and nearby ATC frequency dialog are all useful,
Yes!
and would be a
major regression if not working for the release.
Yes indeed!
I can't see any downside to removing the conditional compilation completely
now, but I'll leave it 24
On 12/24/2010 01:53 PM, Mirko Stanisak wrote:
I've used Flite to generate voices in ATC simulations (so that you can listen
to the commands between simulated pilots and controllers). It worked quite
well, the speech was understandable quite well, even if it sounded very
artificial. On the
On 12/23/2010 04:58 PM, Dave L wrote:
If you can email me the words and script that would be great. It took quite
a long time to index all the words when I did the original recording - this
should be a lot quicker.
I put up a little care package at
http://www.av8n.com/festival/
The scripts
On 12/23/2010 05:33 AM, Dave L wrote:
At the moment, the spoken ATIS makes little sense anyway since the
phaseology was corrected a while ago but the extra words were not
recorded.
Well, actually the needed words are available. Long ago I wrote a
script to run the words through the
It may not be an entirely good idea to release a FlightGear version without
any usable ATIS.
It appears that ATC/atis.cxx is a stub. It contains only one line of code.
Meanwhile there is ye olde ATCDCL/atis.cxx, which contains code but is
deprecated and is not compiled in the standard
On 07/23/2010 05:12 AM, Csaba Halász wrote:
./configure: line 10540: apr-1-config: command not found
./configure: line 10541: apr-1-config: command not found
That configure test is broken.
I agree.
It has been broken for a long time ... since well before the
previous release.
The fix is
On 04/07/2010 07:06 PM, Peter Brown wrote:
Perhaps this has been brought up before, but I see that the ILS
beam data for each airport on the mpmap is derived from the runway
alignment (as verified in taxidraw).
That sounds like a problem.
This doesn't allow for magnetic
deviation, and
On 04/03/2010 10:21 AM, dave perry wrote:
I get the following error compiling fgfs.
/usr/bin/ld: cannot find -lopenal
But /usr/lib64/libopenal.so.0 = libopenal.so.1 = libopenal.so.1.11.753.
Note that libopenal.so (with no suffix) is not listed.
My .bashrc has the line
export
On 03/20/2010 03:09 PM, David Megginson wrote:
There's a bug in the /instrumentation/nav/radials/selected-deg
property: the code mistakenly assumes that the selected radial is in
true degrees, but isn't a bearing -- it's just a number. You could
design a VOR where radial 180 was north of the
First, a parable:
The local supermarket sells shiitake mushrooms for
$5.00 per ounce. About a mile down the road there
is an ethnic market that sells the same kind of
mushrooms for $5.00 per *pound*.
You might have been told in high school that this
kind of thing can never
1) I closed the bug-tracker issue concerning the taxiway
signs. That's all good.
2) Alas there are other scenery elements that still
exhibit an improper dependence on camera tilt angle.
Example:
http://www.av8n.com/fly/fgfs/img48/pole-dark.png
in contrast to
On 03/12/2010 06:54 AM, Tim Moore wrote:
I've checked in a fix for the sign-back problem. The airport sign code is
not fast graphics code and needs another look, but for the moment it works.
1) Thanks, the signs are much improved.
2) The problem is not entirely gone. The window for
observing
On 03/12/2010 12:05 PM, Tim Moore wrote:
I flew over there in the ufo and saw gray sign backs there...
FWIW, if I limit the flight to the default screensize and
default field of view, I find it difficult to reproduce
this bug.
On the other hand, if I expand the screen to HDTV size
and/or zoom
On 03/12/2010 04:10 PM, Tim Moore wrote:
There shouldn't be any black or white
sign backs in the most recent code.
Please say what commits constitute the appropriately
recent code, so I don't need to grovel through the
logs ... or at least so that I know what I'm looking
for when I grovel
On 03/12/2010 05:13 PM, Tim Moore wrote:
262383395d78565
OK!
Sign backs are all nice and gray now.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
What steps will reproduce the problem?
--lat=37.637855 --lon=-122.414915 --altitude=656 --heading=113 --fdm=ufo
aircraft is stopped. zero airspeed, zero rate of turn, etc.
The choice of aircraft doesn't seem to matter; this is 100%
reproducible chez moi using the default c172p, the pa24-250,
On 03/10/2010 01:47 AM, Torsten Dreyer wrote:
I did not commit the 6-axes fix for the following reason:
If we change the protocol anyway, why not do it right an support the maximum
number of axes from plib (currently 16)?
The following idea is better:
I'd suggest sending the number of
I observe the following. Lots of irrelevant stuff snipped:
Setup:
fgfs --httpd=5400
lynx -source -head http://localhost:5400/sim/intl/locale/strings/
Result:
Making HTTP connection to localhost:5400
Alert!: Unexpected network read error; connection aborted.
WARNING: netBufferChannel:
On 03/03/2010 06:13 AM, Alasdair wrote:
I am using FG cvs and have recently noticed that commands such as:
fgfs --prop:/instrumentation/nav/radials/selected-deg=63
no longer have any effect.
--prop:/instrumentation/nav/frequencies/selected-mhz=108.90
works fine.
I observe the same bug
On 03/02/2010 01:08 AM, Tim Moore wrote:
Furthermore, I can't parse the suspend development comment. It is coming
from some alternate reality of git usage.
We are definitely talking about two different realities.
First off, I did identify the
commit id where you made changes to use
On 03/02/2010 12:39 PM, luca nastro wrote:
I need an information.
The recording and playback generates a file flight.out,
I assume you used a command similar to
--generic=file,out,20,flight.out,playback
If this assumption is not correct, please ask a more
specific question.
what are
On 03/01/2010 04:13 PM, Tim Moore wrote:
I'm looking at io/sg_file.cxx in the sport branch. I see the old
implementation of readline inside an
execrable_readline #ifdef. I don't see any other implementation of
readline.
Perhaps my question would go away if I fetched your sport flightgear
On 02/15/2010 03:19 AM, Tim Moore in part wrote:
readline() is pretty gross;
The best way to remove the grossness is to extirpate
readline and replace it with something that has a
nicer interface ... such as returning a std::string.
I wrote a getline function to do this. Much cleaner.
No
On 02/21/2010 01:25 PM, Stuart Buchanan wrote:
I think you may be looking at an out-of-date version of
the getstart manual.
I don't think so. cvs up says my copy is already up to
date. The log includes updates through 28 Jan 2010. The
passages I quoted earlier were quoted from this
On 02/20/2010 02:23 AM, Erik Hofman wrote:
Well, The Null-FDM does what is say, nothing. It's expected that an
external application fill in the gaps. I did once create a support FDM
for ACMS (black-box) data but I don't think it touches anything but
position and velocity data.
I guess
On 02/20/2010 07:01 AM, I wrote:
-- Replaying /engines/engine[0]/rpm has no effect ... even though
setting the same property via the property browser has the
expected effect: causing the engine to spin at the specified
rate.
...
It's one thing to say more properties need to be set ...
I recently discovered that it is possible to fly the C172p
(and presumably lots of other aircraft) using --fdm=ufo.
This has the potential to be very useful, for instance if
you want to pose the aircraft for pictures, and for navaid
flight check missions.
This really ought to be documented.
Here's a mystery for you: Please take a look at
http://www.av8n.com/fly/fgfs/img48/null-fdm-instruments.png
Most of the instruments are working, but the rate-of-turn
indicator and the Nav 1 CDI/GS needles are frozen. You
can see from the property browser that the Nav receiver is
properly
On 02/19/2010 05:59 PM, S Andreason wrote:
I ran into the same problem with using generic instruments when
developing the bluebird over 2 years ago. Some instruments rely on
properties that are only updated by the FDM, and the ufo doesn't.
That's valuable information. Can you be more
On 02/18/2010 04:07 AM, Rob / EViLSLuT wrote:
Is the syntax of the robots.txt correct? Could be wrong.
Well, technically, it should say Googlebot instead of just
Google. But this is such a common mistake that Googlebot
answers to the name Google, and no harm is done.
To my knowledge this is
On Mon, Feb 15, 2010 at 5:43 PM, I wrote:
2) It would be even less of a problem to do the following
the specified number of times:
-- detect the EoF
-- close the file
-- reopen the file and start reading again.
This has the advantage that it works the same as lseek
for regular disk
On 02/08/2010 08:34 AM, Geoff McLane wrote:
you seem to be yelling something.
On 02/16/2010 11:47 AM, Geoff McLane wrote:
It seems WHATEVER the reason is, IF it involves
a SimGear AC_CHECK_LIB() then _REMOVE_ the
AC_CHECK_LIB() from SG configure.ac ;=))
There is no reason to check
On 02/16/2010 11:27 AM, Curtis Olson wrote:
Here's one possible idea. Why not whip together a replacement front page
and maybe a sample sub-page, put it in a temporary location, and we can take
a look.
That's a great idea.
Taking the next step along that road, it would be
nice to bring
On 02/16/2010 01:45 PM, John Denker wrote:
OK, I think we can put this sub-issue to bed.
I fixed it so that compiling and installing simgear
no longer requires the OSG or OpenThreads runtime
libraries. The *.h header files are still required.
This turned out to be easier than I thought
On 02/12/2010 01:34 AM, I wrote:
I haven't yet made the corresponding
fixes to the FG side of things.
Well, I finally got around to it.
The patch can be found in the usual place:
http://gitorious.org/~jsd/fg/sport-model/commits/sport
The commit message says:
Fix bug: substrings in
On 02/15/2010 03:19 AM, Tim Moore wrote:
Some of
the grossness is due to a hack which lets a file be treated as an infinitely
repeating stream of bytes, very convenient for demos at SIGGRAPH. Your patch
breaks that hack. I won't argue too strongly that the hack belongs in
SGFile, but I want
On 02/15/2010 09:22 AM, Tim Moore wrote:
Hint: The sleep statement ensures that the reader (fgfs)
will not see an EoF at the point where one cat of bytes
ends and the next begins.
I'd probably do without the sleep and write while true; do cat bytes;
done /tmp/pipe.flog instead.
1) That
.
A lot of stuff I do makes more sense if you look
at it from the Joe User point of view.
I will fix up the FG side of things eventually.
commit 5764d1b7da5cb25947f6ada47aa45fe6b2272cec
Author: John Denker j...@av8n.com
Date: Mon Feb 15 14:50:29 2010 -0700
Fix sneaky bug: 'mylibdir
The following commit message should be self-explanatory:
commit 224ce694fa8ba7dede0e413b81e5dd52e5e65f15
Author: John Denker j...@av8n.com
Date: Thu Feb 11 21:13:19 2010 -0700
Problem was: readline writes out-of-bounds, corrupts memory.
Problem was: readline seeks on files that don't
4eb51bb90f4e8c2ca9842ad248b5e0eb57e400f7
Author: John Denker j...@av8n.com
Date: Fri Feb 12 01:25:25 2010 -0700
Fix bug: substrings in LDFLAGS
Fix bug: substrings in CPPFLAGS
Fix bug: now check libraries (not just headers) for plib.
More informative error messages.
Spelling
a few lines of
interesting code. The patch looks bigger than
that because I tried to normalize some of the
indentation and other trivial issues.
commit 237265e977cf775c5adbff813517381a2d4abe3c
Author: John Denker j...@av8n.com
Date: Fri Feb 12 13:20:13 2010 -0700
Fix it so
On 02/11/2010 01:41 AM, Stuart Buchanan wrote:
A number of people with ATI cards are having problems with the
default shaders on the current windows v2.0.0 RC:
I'm not surprised. The weird dark pall has been #1
on my list of FG bugs for months. The bug is known to
be shader-related.
The
On my machine I observe that the various scripts in
the Nasal/ directory get loaded in some hard-to-predict
order.
That means that if you write a script called foo.nas,
it's hard to know whether it will get processed before
or after math.nas and/or props.nas.
So the question is, what to do if
On 02/11/2010 04:11 PM, Csaba Halász wrote:
On Thu, Feb 11, 2010 at 10:59 PM, John Denker j...@av8n.com wrote:
On my machine I observe that the various scripts in
the Nasal/ directory get loaded in some hard-to-predict
order.
That means that if you write a script called foo.nas,
it's hard
On 02/11/2010 04:14 PM, jean pellotier wrote:
a temporary fix is to remove the gl_FrontMaterial.ambient part in 3
files,
Wow! Direct hit!
here's the diff:
That makes a huge improvement. I'm running with shader-effects
turned on now, for the first time in months.
Thanks!
Has anybody used the --generic record/playback feature
recently?
It seems to have some very noticeable bugs:
When using the --generic record/playback feature, I
observe numerous view-related problems:
* Helicopter view: the size of the aircraft throbs
at a high rate, getting bigger and
On 02/09/2010 12:43 PM, Curtis Olson wrote:
The first thought that comes to mind is to double check the precision
(significant digits) of the data you are writing out. If you are writing
out heading for instance with 0 or 1 decimal digits or position with 4
decimal digits, that could account
?
commit 21f8a5cb05b7f3cc054e1821380c2dcc2322add8
Author: John Denker j...@av8n.com
Date: Tue Feb 9 15:17:30 2010 -0700
latitude and longitude need to be handled as DOUBLE precision
diff --git a/Protocol/playback.xml b/Protocol/playback.xml
index 1b4b3ab..ff09489 100644
On 02/09/2010 01:14 PM, Curtis Olson wrote:
Right, I wouldn't consider playback.xml to be the most well conceived
generic protocol configuration file, ...
Is there some other protocol file that should be
used instead?
None of the other Protocol/*.xml files seem
particularly suited to the
One thing I'd like to clarify:
I wish people wouldn't be so quick to assume that
Joe User is a non-programmer and/or an idiot.
I never said that, and I never meant to imply that.
Let's suppose Joe has a PhD in biochemistry, and
has written 100,000 lines of code in the last few
years.
There are
First, a specific question: Is there any reason why,
when the simulator is paused, the http property browser
should be stalled? I would have expected the network
interface to be completely asynchronous.
This is an important question, because one of the big
reasons for pausing the simulator
On 02/08/2010 08:34 AM, Geoff McLane wrote:
But that seems beside the point. The configure
script _DID_ tell you it could _NOT_ find the
OSG libraries - you just ignore it. You did not
heed its clear indication that you were headed
into trouble...
That statement is completely false.
There
On 02/08/2010 10:58 AM, Geoff McLane wrote:
But John, what IS the _BUG_ you refer to?
Thank you for asking.
Your bug list page only points out osgFX
library could not be found. This is NOT a BUG!!!
Definitely a user OSG installation problem, but
_NOT_ a SG/FG BUG!
Are you asking me or
At KSQL there is reproducibly a building sitting
partially on a taxiway and even extending onto
the runway a little bit.
http://www.av8n.com/fly/fgfs/img48/ksql-building-on-rwy.png
--
The Planet: dedicated and
getValueTypeString( const
SGPropertyNode *node )
==
commit 92b369deb2654351ce4e385a773ccbe01113ce14
Author: John Denker j...@av8n.com
Date: Sun Feb 7 02:37:55 2010 -0700
Export the code that translates the _type_ of a property node
to a human-readable string
Hi --
I made multiple improvements to the http property browser.
-- much easier to navigate up the tree
-- clearer indication of property type
-- possible to re-examine property that has just been set
See
http://gitorious.org/~jsd/fg/sport-model/commits/sport
=
On 02/06/2010 02:32 AM, Erik Hofman wrote:
As I see it this might actually be a problem for the Linux vendor. They
should have added /usr/lib64 to /etc/ld.so.conf
That does not fix the main problem. It does not fix
the bug that I am reporting.
ld.so.conf is meaningful at runtime. The
On 02/06/2010 07:54 AM, Csaba Halász wrote:
On 64 bit systems /lib64 should really be a symlink to /lib (similarly
for /usr/lib64) as that is the native architecture.
I say copy the stuff from lib64 to lib and create the symlink.
That is one way of doing it.
By my count there are at least
On 02/06/2010 08:06 AM, Erik Hofman wrote:
That does not fix the main problem. It does not fix
the bug that I am reporting.
The problem you reported is that the linker can't locate the library.
If it's location is defined in ld.so.conf (and after running ldconfig)
it can.
No, that is
in getstart.pdf or
in the --help --verbose message.
commit 3a4e6c2177b05ac14002e6795abaa6c5582c31c8
Author: John Denker j...@av8n.com
Date: Fri Feb 5 08:50:09 2010 -0700
More informative error message.
diff --git a/simgear/structure/exception.cxx b/simgear/structure/exception.cxx
index
I'm glad to see people are cleaning up the autoconf stuff.
Here's yet another area that needs some TLC: There appears
to be little or no chance that the autoconf system will do
the right thing on 64-bit machines.
I'm hoping this will be easy for some autoconf guru to fix.
I would imagine
still
good to check.
commit cc188f7499c03417b1d4a3cb296702ba7b4d67fa
Author: John Denker j...@av8n.com
Date: Fri Feb 5 10:12:15 2010 -0700
Write pid into property tree and optionally into a file.
diff --git a/src/Main/main.cxx b/src/Main/main.cxx
index d5ac553..38202e4 100644
On 02/05/2010 11:26 AM, leee wrote:
Are those clouds on the horizon or is it distant scenery?
Scenery. Mountainous terrain. Clearly recognizable as such.
No clouds anywhere:
METAR 012345Z 0KT 99SM CLR 15/M01 A2992
If it's
scenery then funnily enough, back in Feb2008, I
On 02/05/2010 02:38 PM, Curtis Olson wrote:
I don't doubt that there could be some lib vs. lib64 inconsistencies, but
FilghtGear builds right out of the box for me on 64bit Fedora 12 ... no
hitches at all that I recall and it has done so for quite some time.
Chez moi plib and simgear install
On 02/05/2010 03:17 PM, Curtis Olson wrote:
Do you have details of the configure or make error you are seeing posted
somewhere?
Yes. Please take a look at
http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit
As it says there:
make[1]: Entering directory `/mnt/games/orig/fgs/tests'
g++
Let summarize a few obvious points:
1) Everybody who is participating in this conversation
is doing so in order to help ordinary non-expert users.
None of use will directly benefit from any cleanup
in the autoconfiguration scripts.
Everybody on this list is an expert. We all figured
out years
On 02/05/2010 06:43 PM, Curtis Olson wrote:
This simply isn't the case as I have observed it. Everything compiles out
of the box here. I have access to two 64 bit Linux machines. I run Fedora
if that makes a difference. OSG, FlightGear, Simgear, plib go together
without expert magic using
Here’s the setup: Start the program as
fgfs --airport=KLXV --metar= 012345Z 0KT 99SM CLR 15/M01 A2992
Let the aircraft sit on the runway. There is no need to start the engine. Use
the v key to cycle through the available views. The scenery looks normal
until you get to the last
On 02/03/2010 12:22 AM, Tim Moore wrote:
This might be associated with the replay system, and I don't see a good way
to turn it off completely. Try starting with /sim/replay/disable set to true
and see if that changes anything.
No change.
Also FWIW turning off random vegetation = no change.
On 02/03/2010 01:37 AM, Tim Moore wrote:
What hardware and driver? A possible workaround is to comment out the
conditional tests related to gl_FrontFacing
in Shaders/default.frag and Shaders/mat-anim.frag.
Tim
Whoops, never mind. Try the Shaders/mat-anim.frag that I just checked into
CVS
On 02/03/2010 02:00 AM, Tim Moore wrote:
Do you still get it now, after the shader errors have
(hopefully) been banished?
Three answers:
1) The shader issue is greatly improved. No more nasty
shader-related error messages on the console. This is
an improvement at all airports, not just
On 02/02/2010 07:41 AM, Francesco Angelo Brisa wrote:
Do you need me to create deb packages for ubuntu (9.10)/debian(5.0) for
this release ?
Well, it would be nice if somebody would create such
things.
if yes I need to know a couple of things:
1) where to get the exact fgfs/simgear/osg code
On 02/01/2010 10:52 AM, Durk Talsma wrote:
Here's just a quick update regarding the 2.0.0 release. The final release is
really close now. We had planned to have a third release candidate by now,
which we would promote to the final release within a few days from now,
provided that no
Hi --
When terrasync is running, are the updates atomic?
I suspect not, since terrasync depends on svn, and
AFAIK svn commits are atomic but checkouts are not.
I've seem some pretty weird irreproducible results
which might be explained by FG reading half of a
new file plus half of an old file
I observe that the memory usage of FG increases steadily
at the rate of 144 megabytes per minute for at least
the first 7 minutes.
That seems rather far outside the acceptable range.
As you might expect, this is associated with dramatic
degradation of the frame rate and other ugliness.
This
1 - 100 of 515 matches
Mail list logo
