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 pe
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 ma
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 c
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, perhaps
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
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:
> http://m
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
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 look
On 09/15/2011 03:08 PM, HB-GRAL wrote:
> No, it looks like the mapping with apt.dat data is inaccurate, at least
> outside the United States.
The following repeats an email I sent quite a while ago,
which somehow seems to have gotten lost:
On 09/10/2011 03:54 PM, HB-GRAL wrote:
> I am just cu
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
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 so
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.
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
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 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.flightgea
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/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 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 u
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 commit
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".
--
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 tailwind
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!
---
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
> 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/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 scrip
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 o
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 festi
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 configu
On 12/20/2010 05:42 AM, henri orange wrote:
> At FG load, i get a lot of these warning messages:
>
> TangentSpaceGenerator: unknown primitive mode 9
>
> Is it just me ? is there any possibility to avoid it ?
It's not just you.
There are at least two or three bugs involved here.
1) It is a b
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 fi
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, a
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 t
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 happ
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
http://www.av8n.com/fly/fgfs/im
On 03/12/2010 05:13 PM, Tim Moore wrote:
>> 262383395d78565
OK!
Sign backs are all nice and gray now.
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactiv
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 thr
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 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
observin
On 03/11/2010 03:15 PM, Tim Moore wrote:
> The mesh representing the back of a sign is not complete; graphics state
> from other parts of the scenery are leaking into it. The particular effect
> depends on the global draw order, which does change as your viewing angle
> changes.
Thanks for the ra
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,
e
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: o
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 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/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 g
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 flightg
On 03/01/2010 03:56 PM, Tim Moore wrote:
> getline looks fine.
:-)
> Instead of getting steamed about readline, why not
> implement it in terms of getline?
I did.
If this is really a question, please clarify the question.
--
On 02/25/2010 02:26 PM, Grimes, John R Mr CTR USAF AFMC AFRL/RWGG wrote:
> I am currently running FlightGear 2.0.0 (snagged from the ibiblio ftp
> site) that I compiled on my Ubuntu 9.10 64 bit system. Compiled up no
> problem, but I have noticed that when I attempt to setup a master/slave
> scena
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 nee
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 vers
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
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/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 spec
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 tune
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.
Co
On 02/19/2010 01:48 AM, Erik Hofman wrote:
> I've created a new set of splash screens based on the images Durk
> created about two weeks ago.
> Does anyone have any objections to committing them or does anybody have
> other possible splash screens to choose from?
>
> http://home.telfort.nl/sp004
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 th
On 02/17/2010 04:54 PM, Jon Stockill wrote:
> Presumably because there are some truly awful bots out there, and google
> at least is known to be well behaved.
But the truly awful bots don't look at robots.txt.
In fact one of the easiest ways to catch rogue bots
is to disallow a small part of th
http://wiki.flightgear.org/robots.txt
User-agent: Google
Disallow:
User-agent: *
Disallow: /
#User-agent: Slurp
#Crawl-delay: 5
#Disallow:
=
Really? A collective, open-source project that doesn't
allow anybody other than google to index the documentation?
Is there a reaso
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 r
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 LDFLA
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 it
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/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
in lib64/ by default.
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
Date: Mon Feb 15 14:50:29 2010 -0700
Fix sneaky bug: '
On 02/15/2010 09:22 AM, Tim Moore wrote:
> a useful command-line option.
The "repeat" sub-option would be even more useful if
it were more widely known. It is not mentioned in
--help --verbose and not mentioned in getstart.pdf.
It would be nice if somebody would
a) At least mention README.I
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.
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 w
The following commit message should be self-explanatory:
commit 224ce694fa8ba7dede0e413b81e5dd52e5e65f15
Author: John Denker
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 support
The attached patch contains only 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
Date: Fri Feb 12 13:20:13 2010
things.
commit 4eb51bb90f4e8c2ca9842ad248b5e0eb57e400f7
Author: John Denker
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.
Spelli
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!
--
On 02/11/2010 04:11 PM, Csaba Halász wrote:
> On Thu, Feb 11, 2010 at 10:59 PM, John Denker 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 sc
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 fo
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.
Th
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 re
e and longitude. What am I missing?
commit 21f8a5cb05b7f3cc054e1821380c2dcc2322add8
Author: John Denker
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 1b4
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 acco
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 sma
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 managed
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 o
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.
Th
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 is
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 *
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
=
S
getValueTypeString( const
SGPropertyNode *node )
==
commit 92b369deb2654351ce4e385a773ccbe01113ce14
Author: John Denker
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.
diff --git a
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, tha
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 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 prob
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 usi
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 a
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++
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 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 r
x27;s still
good to check.
commit cc188f7499c03417b1d4a3cb296702ba7b4d67fa
Author: John Denker
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
--- a/src
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 there
1 - 100 of 576 matches
Mail list logo
