On Fri, Feb 5, 2010 at 7:30 AM, Heiko Schulz aeitsch...@yahoo.de wrote:
Hi
I don't see any new sceneries which are
clobbered.
You yourself said in another
email:
-Framerates in KSFO 28R less than used to. Usually I
get up to 60 fps
with everything enabled in FGFS, but
Jari Häkkinen wrote:
Maybe the issues described above are valid only for my local build
[...]
You might check if things look differently when using a build from
current CVS,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
On Thu, Feb 4, 2010 at 12:03 PM, Martin Spott martin.sp...@mgras.netwrote:
Hi Tim,
Tim Moore wrote:
I haven't looked at NYC in a while, but our urban areas tend to get
clobbered, particularly when the scenery guys strut their stuff for a new
release.
The vast majority of the changes
Tim Moore wrote:
By the way, the new hotness in terrain visualization seems to be
creating buildings from shape files that encode the height of each
building, with a big texture (extracted from a bigger image) that has an
image of each roof. If you assume that buildings are prisms, an
Ok, so this really bounces to Tat. Tat, the flightgear source you use is
based on what's in git ... looking into
fg/source/src/Navaids/navrecord.cxx reveals that the CVS version has
some more control code that avoid the issues I reported in this thread.
Tat, can you look into this?
Martin,
Hi
That's the correct definition. I
meant that the frame rate was clobbered. Perhaps
clobbered is a bit strong.
Tim
This gives far more sense then.
For KSFO it would maybe help to change the power pylons. Currently it is one
sized .ac-model but which is changed in size per
Hi,
Just wanted to know if anybody was working on it so I don't duplicate wnat
other people are doing.
Do I understand correctly you are doing a 3D model and such of a 747?.If so I
won't bother with the
current 747-400
Most of it is already in CVS for quite a while. Under
Heiko Schulz wrote:
Hi
That's the correct definition. I
meant that the frame rate was clobbered. Perhaps
clobbered is a bit strong.
Tim
This gives far more sense then.
For KSFO it would maybe help to change the power pylons. Currently it is one
sized .ac-model but which is changed
Heiko Schulz wrote:
For KSFO it would maybe help to change the power pylons. Currently it
is one sized .ac-model but which is changed in size per
scale-animation in .xml.
As we already know every used .xml will slow down, so a big amount of
.xml in a scenery can be deadly (like
Thank you for the fixes and for the super models. I noticed a couple of
things in the Primus1000:
Aircraft/Instruments-3d/primus-1000/P1000.nas
At present, at startup, hitting NAV gumdrop button alternates NAV1/NAV2
pointers but, after hitting FMS button, the pointers will
not revert to
Gijs, why not just create a clone of 747 series in github, or gitorious
, and then that can be merges into CVS later maybe.
pete
Gijs de Rooy wrote:
Hi,
Just wanted to know if anybody was working on it so I don't
duplicate wnat other people are doing.
Do I understand correctly you are
Hi Jari,
I read _LOUDLY_ your 'fear' that changing anything
to do with the 'svn' may cause some unwanted
change... but feel this is totally unfounded...
It seems my explanation that changing -
AC_CHECK_HEADERS([svn_client.h glut.h])
- to -
AC_CHECK_HEADERS([svn_client.h])
would change NOTHING
One of my students recently typed the command
fgfs : echo $?
The result was:
Fatal error: Failed to open file
at :
(received from SimGear XML Parser)
--
Two observations:
1) The student found this error message to be uninformative.
I have to agree; using the word at for
On 2/5/10 4:04 PM, Geoff McLane wrote:
Hi Jari,
I read _LOUDLY_ your 'fear' that changing anything
to do with the 'svn' may cause some unwanted
change... but feel this is totally unfounded...
Yes, I agree. My bad. I added your checks to my configure.ac.
Jari
On 2/5/10 4:04 PM, Geoff McLane wrote:
But I have had more time to write, and test a
BETTER patch attached that :-
(a) does NOT change the svn_client.h lines ;=((,
(a) should be changed, I agree with your original proposal.
Actually I think subversion support in terrasync should be removed
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
Two closely-related new features:
property: /sim/pid
option: --pid=/pathto/some/file.pid
Having the pid available is useful for many purposes,
including sending a signal for debugging.
Somebody should please check that this works under MSVC.
It looks to me like pretty standard c++ but it's
Jari Häkkinen wrote:
Actually I think subversion support in terrasync should be removed
altogether or fixed. If removed then all svn checks could be removed.
Oh my, could you _please_ stop this litany ? One posting of this sort
per day should really be enough, two or more are a nuisance.
I'm stuck up an Alp until Monday, but the AB is likely just the
autopilot Xml entry being accidently removed - I shall check upon my
return to reality.
As for the GPS, please do ask if things seem strange, I'm happy to
make code changes, or document things better. The departure waypoint
Hi Curt,
I quickly saw forum posts about some new 787 aircrafts:
http://www.flightgear.org/forums/viewtopic.php?f=4t=5207.
But I couldn't realize which files should be (or planed to be)
committed to CVS.
So, would you please simply delete the following line in
data/Aircraft/787/787-set.xml in
Martin Spott wrote:
Oh my, could you _please_ stop this litany ? One posting of this sort
per day should really be enough, two or more are a nuisance. According
to my experience you're trying to make people throw the baby out with
the bath water, which is not appropriate here.
which,
Hi,
I'm stuck up an Alp until Monday, but
the AB is likely just the
autopilot Xml entry being accidently removed - I shall
check upon my
return to reality.
Indeed it is removed, but with changing back still doesn't work. Something is
still missing.
The same for the 747-400.
As for
On Friday 05 Feb 2010, John Denker wrote:
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
Hi Jari,
Geoff, how do you make it through the svn check in
configure.ac or really building terrasync?
I don't have any problems ;=)) utils/TerraSync/
terrasync builds without ANY problems in my
64-bit Ubuntu 8.04...
I do _NOT_ have the svn library, nor svn_client.h installed,
but of course
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
Tim Moore wrote:
On Thu, Feb 4, 2010 at 12:03 PM, Martin Spott martin.sp...@mgras.netwrote:
Tim Moore wrote:
I'm referring here to KSFO, and the only change I can point to is that new
KSFO scenery is now in the base package. I tend to be lazy and use that for
most of my testing.
Ah, I see.
-VNAV only follows airports- but not any other Waypoints like VOR, NDB,
fixes
Only when frq turned to VOR
VNAV shouldn't follow ANY waypoint ... so I'm assuming you mean LNAV .
If I understand Jame's gps changes ... I should be able to eliminate my
nasal routines that detect the difference
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.
Regards,
Curt.
On Fri, Feb 5, 2010 at 11:11 AM, John Denker j...@av8n.com
Hi Toshi,
I think my script will build the 787 just fine (or am I missing something?)
I believe the reason it wasn't included automatically in the past was
because it didn't exist is CVS.
Best regards,
Curt.
On Fri, Feb 5, 2010 at 11:49 AM, YOSHIMATSU Toshihide wrote:
Hi Curt,
I quickly
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 Fri, Feb 5, 2010 at 4:05 PM, John Denker wrote:
Chez moi plib and simgear install into lib/
while osg installs into lib64/
How do you get around that? How do recommend I get
around that?
Obviously there are ways, but the only ways I know are
complicated and devious ... not exactly
John Denker wrote:
Chez moi plib and simgear install into lib/
while osg installs into lib64/
How do you get around that?
Either install OSG from your favourite distribution or build with
-D LIB_POSTFIX=
Martin.
--
Unix _IS_ user friendly - it's just selective about who its
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++
How about
./configure --prefix=$parent
Curt.
On Fri, Feb 5, 2010 at 4:46 PM, John Denker j...@av8n.com wrote:
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
And for whatever it's worth, I've been using the default paths for
installing osg (i.e. not specifying any other prefix, I don't know if that
is a key difference in our setups.)
Curt.
On Fri, Feb 5, 2010 at 5:22 PM, Curtis Olson wrote:
How about
./configure --prefix=$parent
Curt.
On
I'm assuming a UNIX/Linux system.
Does configure run clean? Look for libraries that it cannot find.
If that's the problem, and if you're on a linux system, you'll need to
tell configure where to find the libraries.
I usually run:
./configure --help do.it
Add comments before every line, then
Curtis Olson wrote:
It has just worked for me so I have never dug in and tried to think about
/lib vs. /lib64 with respect to FlightGear and it's dependencies.
I'd like to add that Brisa's script (an automated compilation script for
PLIB, OSG, SG, FG, FGCOM, and FGRun) makes a simlink,
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
Hi Curt,
Thanks for your reply.
Certainly, at the release timing of v1.9.0, 787_02_2008.zip was built
and have been distributed via ftp.
But it was not included to the aircraft download page, because
your make-aircraft-html.pl can't handle aircraft version which
includes _ (underbar).
Log of
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 the default configure paths. We could work to
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
On 5 Feb 2010, at 21:14, syd adams adams@gmail.com wrote:
-VNAV only follows airports- but not any other Waypoints like VOR,
NDB,
fixes
Only when frq turned to VOR
VNAV shouldn't follow ANY waypoint ... so I'm assuming you mean LNAV .
If I understand Jame's gps changes ... I should
42 matches
Mail list logo
