Hi
Any assistance would be gratefully accepted.
Debug info:
Compiling...
iochannel.cxx
lowlevel.cxx
c:\documents and settings\sam
ingarfield\desktop\simgear-0.3.9-pre3\simgear\misc\stdint.hxx(80) :
error C2059: syntax error : 'bad suffix on number'
c:\documents and settings\sam
Ok... I myself have been having problems with compiling FG with MSVC
7.1, but I've been told this much. Its way to hard to compile with
MSVC6. But ofcourse, I submit to the judgement of the masters. They
know way better.
On 11/14/05, Sam Ingarfield - VK6HSI [EMAIL PROTECTED] wrote:
Hi
Any
Kevin Jones wrote:
Regarding the file /data/Sounds/intro.mp3:
FlightGear doesn't use OpenAL for MP3 playback. In fact, it isn't even
supported.
Does that mean that the command line options --disable-intro-music and
--enable-intro-music have no effect on any platform or should there be
a
Regarding the file /data/Sounds/intro.mp3:
FlightGear doesn't use OpenAL for MP3 playback. In fact, it isn't even
supported.
Does that mean that the command line options --disable-intro-music and
--enable-intro-music have no effect on any platform or should there be
a different intro-music
Buchanan, Stuart wrote:
OK, I'll suggest /var/share/FlightGear/WorldScenery/[Terrain|Objects] for
*nix, and FG_ROOT\Scenery\[Terrain|Objects] for Windows.
I'm sure you meant /usr/share/FlightGear/... and not /var.
Just to clarify,
Nine
___
Stefan Seifert wrote:
I'm sure you meant /usr/share/FlightGear/... and not /var.
Makes more sense to me.
--
Jon Stockill
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Stefan Seifert wrote:
Buchanan, Stuart wrote:
OK, I'll suggest /var/share/FlightGear/WorldScenery/[Terrain|Objects] for
*nix, and FG_ROOT\Scenery\[Terrain|Objects] for Windows.
I'm sure you meant /usr/share/FlightGear/... and not /var.
Hehe, I've started a similar discussion twice in the
On Sunday 13 November 2005 20:15, Steve Knoblock wrote:
I installed the downgrade of freeglut, but I still get a missing
header error. I think this header is in the freeglut-devel but did not
download that module. I cannot seem to access the 9.3 RPMs in the Yast
repositories. Can someone point
Please do commit them, I've had hand-rolled projects for all three
for some time, but they're out of sync. If I find any issues, I'll
let you know.
Is it worth creating a developer directory under FlightGear CVS to
contain things like these xcode project files and developer
instructions for
On Mon, 14 Nov 2005, Stefan Seifert wrote:
Buchanan, Stuart wrote:
OK, I'll suggest /var/share/FlightGear/WorldScenery/[Terrain|Objects] for
*nix, and FG_ROOT\Scenery\[Terrain|Objects] for Windows.
I'm sure you meant /usr/share/FlightGear/... and not /var.
I thought /var because of the
* Vassilii Khachaturov -- Monday 14 November 2005 12:50:
http://members.aon.at/mfranz/flightgear/flightgear-howto.html
I'd only suggest to have the world scenery under smth like
/var/share/FlightGear/WorldScenery
(maybe share/games) rather than in the FG_ROOT, to make it
more up-to-date
Vassilii Khachaturov wrote:
On Mon, 14 Nov 2005, Stefan Seifert wrote:
Buchanan, Stuart wrote:
OK, I'll suggest /var/share/FlightGear/WorldScenery/[Terrain|Objects] for
*nix, and FG_ROOT\Scenery\[Terrain|Objects] for Windows.
I'm sure you meant /usr/share/FlightGear/... and
On 11/14/05, Ima Sudonim [EMAIL PROTECTED] wrote:
Please do commit them, I've had hand-rolled projects for all three
for some time, but they're out of sync. If I find any issues, I'll
let you know.
Is it worth creating a developer directory under FlightGear CVS to
contain things like
bass pumped wrote:
Ok... I myself have been having problems with compiling FG with MSVC
7.1, but I've been told this much. Its way to hard to compile with
MSVC6. But ofcourse, I submit to the judgement of the masters. They
know way better.
Yes, the general consensus I've heard in the
This would require someone to maintain the project files. I plan on
leaving the FlightGear project soon after the 0.9.9 release so
wouldn't be able to.
Arthur,
If the project files were in cvs, then you personally wouldn't have
to maintain them. Whoever needed to use them would see about
* Curtis L. Olson -- Monday 14 November 2005 15:12:
Let's stick with .../.../Scenery/[Terrain|Objects] on all platforms
please. Individuals are welcome to call it whatever they want on their
system and use the --fg-scenery= option to point to their favoritely
named directory.
Maybe I
Hi WIN32 developers,
I too have had BIG PROBLEMS with compiling OpenAL
CVS with MSVC7.1 - maybe this will eventually be cleared
up by the OpenAL developer group ... maybe NOT ;=((
Part of the problem, is that for no particular good
reason that I see, in WIN32 they, the OpenAL group,
decided to
Melchior FRANZ wrote:
* Curtis L. Olson -- Monday 14 November 2005 15:12:
Let's stick with .../.../Scenery/[Terrain|Objects] on all platforms
please. Individuals are welcome to call it whatever they want on their
system and use the --fg-scenery= option to point to their favoritely
named
A little OT, I would ALSO like to help in WIN32
with cygwin builds, and have begun to try cygwin,
but hit problems with my first try, with PLIB ...
After ./autogen.sh and ./configure (boy, that seems
a SLOW process), when I then run the make, it exits
with -
$ make
Makefile:328: *** missing
Hi Sam,
Although I have personally abandoned MSVC6
in favour of MSVC7.1, ALL should be possible
with MSVC6 - again, my pages -
http://geoffmclane.com/fg
has lots of information on compiling with
MSVC6 ... trials and tribulations ...
Maybe I too will try it again, but
AFTER I experiment with
On Monday 14 November 2005 15:01, Stefan Seifert wrote:
Vassilii Khachaturov wrote:
On Mon, 14 Nov 2005, Stefan Seifert wrote:
Buchanan, Stuart wrote:
OK, I'll suggest /var/share/FlightGear/WorldScenery/[Terrain|Objects]
for *nix, and FG_ROOT\Scenery\[Terrain|Objects] for Windows.
I'm
--- Curtis L. Olson [EMAIL PROTECTED] wrote:
Melchior FRANZ wrote:
Maybe I missed something, but as far as I've understood this thread
is not about renaming $FG_ROOT/Scenery/.
Well ... it could be :)
My aim is to write a section in the Gettings Started Guide so that a new
user can set up
Please do commit them, I've had hand-rolled projects for all three for some
time, but they're out of sync. If I find any issues, I'll let you know.
James
OK, they are available now. I quickly wrote ReadMe's for them.
https://sourceforge.net/cvs/?group_id=126825
To checkout:
cvs -z3
On Monday 14 November 2005 16:06, Buchanan, Stuart wrote:
I'm groping in the dark here as I'm not familiar with terrasync. Am I
correct in thinking that someone using terrasync should have their
terrasync data in a different directory from their directly-downloaded
10x10 scenery?
If so, is
* Buchanan, Stuart -- Monday 14 November 2005 16:06:
Am I correct in thinking that someone using terrasync should have their
terrasync data in a different directory from their directly-downloaded
10x10 scenery?
No. On the contrary.
If so, is the convention to name the directories as
Melchior FRANZ wrote:
This dir doesn't exist. There's no such thing as $FG_ROOT/data/.
Of course there is. :-)
$FG_ROOT/source/
$FG_ROOT/data/
$FG_ROOT/data/Aircraft/
$FG_ROOT/data/Scenery/
This is the prefered structure ...
Regards,
Curt.
--
Curtis Olson
Buchanan, Stuart wrote:
--- Curtis L. Olson [EMAIL PROTECTED] wrote:
Melchior FRANZ wrote:
If so, is the convention to name the directories as follows:
$FG_ROOT/data/Scenery - standard SF bay scenery included in base package
$FG_ROOT/Scenery - scenery downloaded in 10x10 chunks
* Curtis L. Olson -- Monday 14 November 2005 16:34:
Melchior FRANZ wrote:
This dir doesn't exist. There's no such thing as $FG_ROOT/data/.
Of course there is. :-)
Sheesh. I resign. :-}
$FG_ROOT/source/
$FG_ROOT/data/
$FG_ROOT/data/Aircraft/
$FG_ROOT/data/Scenery/
This is the
Curtis L. Olson wrote:
Melchior FRANZ wrote:
This dir doesn't exist. There's no such thing as $FG_ROOT/data/.
Of course there is. :-)
$FG_ROOT/source/
$FG_ROOT/data/
$FG_ROOT/data/Aircraft/
$FG_ROOT/data/Scenery/
Curt, this does not necessarily work. Apparently you have been
--- Martin Spott [EMAIL PROTECTED] wrote:
Buchanan, Stuart wrote:
--- Curtis L. Olson [EMAIL PROTECTED] wrote:
Melchior FRANZ wrote:
If so, is the convention to name the directories as follows:
$FG_ROOT/data/Scenery - standard SF bay scenery included in base
package
Melchior FRANZ wrote:
* Curtis L. Olson -- Monday 14 November 2005 16:34:
Melchior FRANZ wrote:
This dir doesn't exist. There's no such thing as $FG_ROOT/data/.
Of course there is. :-)
Sheesh. I resign. :-}
$FG_ROOT/source/
$FG_ROOT/data/
Martin Spott wrote:
Curt, this does not necessarily work. Apparently you have been
misunderstood by several people for a long time. This makes the
topic really funny :-)
Looking at the facts, 'fgfs' actually does find the aircraft model,
when data/ resides _below_ $FG_ROOT, but it does _not_
Buchanan, Stuart wrote:
OK, so I think I'd like to suggest that for the Getting Started Guide we
suggest for Windows
whatever_path_to_FG/data/Scenery
whatever_path_to_FG/Scenery
and for *nix
$FG_ROOT/Scenery
/usr/share/FlightGear/Scenery
I'm expecting that *nix users will be familiar enough
* Curtis L. Olson -- Monday 14 November 2005 16:54:
This is a hopeless conversation because everyone wants to do it
different and there are so many possibilities.
We are talking about different things. You talk about the organization
of source and data in your home directory. I talk about
Melchior FRANZ wrote:
* Curtis L. Olson -- Monday 14 November 2005 16:54:
This is a hopeless conversation because everyone wants to do it
different and there are so many possibilities.
We are talking about different things. You talk about the organization
of source and data in your
On Monday 14 November 2005 16:58, Curtis L. Olson wrote:
We can suggest different default locations of $FG_ROOT for different
systems, but below $FG_ROOT we should use the same structure for all
platforms.
Curt.
Then we should definitely officially use /usr/local/games/flightgear/
or
Hi Sam,
Curt wrote :
simply too old and buggy
While I might agree with the AGE, circa 1998, 7
years might be the life expectancy of a compiler ;=))
I do not think I could characterise it as 'buggy' ...
quirky, kinky, and as I used below, 'blind' ...
or simply lacking in SOME newer C++, albeit
Here's an interesting one:
When flying thru a cloud layer, that layer either disappears or becomes a
solid cloud bank, which is fine when the viewpoint is from the cockpit.
However, if the viewpoint is from the tower, or perhaps by extension, from
another plane in multi-player mode (I can't
Oliver C. wrote:
To make use of /usr/local/games/flightgear/ or /opt/flightgear/ by
default we
should change the configure script accordingly.
As FlightGear is a self contained package (including binaries, libs and
data) it belongs to /opt/flightgear according to the FHS. Which would
also
Oliver C. wrote:
Then we should definitely officially use /usr/local/games/flightgear/
or /opt/flightgear/ as $FG_ROOT on unix systems.
I don't understand why the hell people should want to use
/usr/local/games/ for FlightGear ?
Just curious,
Martin.
--
Unix _IS_ user friendly -
Josh Babcock wrote:
Ima Sudonim wrote:
Probably accurately displaying the borders of parks and forested areas
could help with VFR, no? (this is not to imply that the borders are not
accurate, I don't know but it might be worth looking into)
Again, a function of how accurate the VMAP data
On Monday 14 November 2005 18:05, Martin Spott wrote:
Oliver C. wrote:
Then we should definitely officially use /usr/local/games/flightgear/
or /opt/flightgear/ as $FG_ROOT on unix systems.
I don't understand why the hell people should want to use
/usr/local/games/ for FlightGear ?
That's
Martin Spott wrote:
Oliver C. wrote:
Then we should definitely officially use /usr/local/games/flightgear/
or /opt/flightgear/ as $FG_ROOT on unix systems.
I don't understand why the hell people should want to use
/usr/local/games/ for FlightGear ?
The slackware package puts the binaries
* Harald JOHNSEN -- Saturday 12 November 2005 17:09:
Melchior FRANZ wrote:
I've just implemented the check for stale METAR reports (to stop
fetching after 10 stale reports). This triggers an assert in
SGThread:
It's perhaps because of the PTHREAD_CREATE_DETACHED attribute of the thread.
Oliver C. wrote:
Seriously, i can live with both directories.
/opt/flightgear is fine too.
Great - should we focus on this one for documentation purpose ?
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
Martin Spott wrote:
Several people did comparisons between VMAP0 data and reality and it
looks like VMAP0 is not very accurate at all in this area. I expect
that we an offer a guide to the community in the not so distant future
that explains how people can improve the landcover data and submit
Melchior FRANZ wrote:
* Harald JOHNSEN -- Saturday 12 November 2005 17:09:
Melchior FRANZ wrote:
I've just implemented the check for stale METAR reports (to stop
fetching after 10 stale reports). This triggers an assert in
SGThread:
It's perhaps because of the PTHREAD_CREATE_DETACHED
* Oliver C. -- Monday 14 November 2005 18:46:
[/usr/local/games/FlightGear or /opt/flightgear]
Seriously, i can live with both directories. /opt/flightgear is fine too.
Both are wrong, according to the FHS, and to common sense. The right path
is /usr/local/share/ ... and guess what? It's
Hi,
Martin Spott schrieb:
Several people did comparisons between VMAP0 data and reality and it
looks like VMAP0 is not very accurate at all in this area. I expect
that we an offer a guide to the community in the not so distant future
that explains how people can improve the landcover data and
Stewart Andreason wrote:
Here's an interesting one:
When flying thru a cloud layer, that layer either disappears or becomes a
solid cloud bank, which is fine when the viewpoint is from the cockpit.
However, if the viewpoint is from the tower, or perhaps by extension, from
another plane in
* Erik Hofman -- Monday 14 November 2005 18:47:
If it's causing any troubles I would remove the first three lined of
SGThread::start() since we've done without it for many years.
It is causing troubles: the pthread_join manpage says:
The joined thread th must be in the joinable state: it
Buchanan, Stuart wrote:
--- Martin Spott [EMAIL PROTECTED] wrote:
OK, so I think I'd like to suggest that for the Getting Started Guide we
suggest for Windows
whatever_path_to_FG/data/Scenery
whatever_path_to_FG/Scenery
and for *nix
$FG_ROOT/Scenery
/usr/share/FlightGear/Scenery
But why
--- Melchior FRANZ [EMAIL PROTECTED] wrote:
Both are wrong, according to the FHS, and to common sense. The right
path
is /usr/local/share/ ... and guess what? It's already the default. So,
What is FHS?
So for consistency in the docs (and ignoring power users like the people
who inhabit this
Hi All,
As with 0.9.9 we'll be using the FG scenery DB objects, will the default
scenery directory topology be something this
Scenery/Terrain/w010n50
Scenery/Objects/w010n50 ?
Assuming this is the case -
a) Should this be what is mentioned in the Getting Started Guide as the
way scenery is
I've seen a couple of Failed to open file messages w/o a file,
and decided to hunt for that one. It looks like this is only
thrown from within simgear, but always with a path.
Closer examination reveals that easyxml.cxx throws it, and uses the same
pattern as JSB and I had recently agreed to
Hi All,
As with 0.9.9 we'll be using the FG scenery DB objects, will the default
scenery directory topology be something this
Scenery/Terrain/w010n50
Scenery/Objects/w010n50 ?
I suggest encouraging 2 directories --- 1 for the static scenery
coming with FG, and the other one for the
On 12 Nov 2005, at 14:30, Arthur Wiebe wrote:I've been using Xcode 2.2 for some time now building Flightgear and everything else. Preview builds until now of course.By the way Xcode projects you can use to build PLIB, Simgear, and FlightGear are available now. I've polished them up so they should
--- Vassilii Khachaturov [EMAIL PROTECTED] wrote:
Scenery/Terrain/w010n50
Scenery/Objects/w010n50 ?
I suggest encouraging 2 directories --- 1 for the static scenery
coming with FG, and the other one for the Terrasync DB/Jon's database/
whatever else external source. Melchior has it
Additionally no one should run terrasync as root anyway, so it can't
write to /var/share/FlightGear. terrasync users should have their own
scenery directory in their homes or anywhere their user is able to write.
Nine
I agree.
User data (like from terrasync) belong to
Vassilii Khachaturov wrote:
I thought about a dedicated account for terrasync (non-root),
with right permissions only to the /var/share/FlightGear/Scenery/Terrain
(or WorldScenery/Terrain).
Terragear is sufficiently crude and unrefined and user unfriendly that I
think we should leave it
On Monday 14 November 2005 19:07, Buchanan, Stuart wrote:
--- Melchior FRANZ [EMAIL PROTECTED] wrote:
Both are wrong, according to the FHS, and to common sense. The right
path
is /usr/local/share/ ... and guess what? It's already the default. So,
What is FHS?
It's the unix Filesystem
On Monday 14 November 2005 18:47, Melchior FRANZ wrote:
* Oliver C. -- Monday 14 November 2005 18:46:
[/usr/local/games/FlightGear or /opt/flightgear]
Seriously, i can live with both directories. /opt/flightgear is fine too.
Both are wrong, according to the FHS, and to common sense. The
Terragear is sufficiently crude and unrefined and user unfriendly that I
think we should leave it out of the getting started guide. We are going
to send unsuspecting users down a wild goose chase and they'll be
disappointed. We can mention it and forward them to more information,
but I
Unfortunately, reverting the recent changes (that caused the thread
to be created with detached state) wasn't enough to fix the problem.
The strange thing is, that the return value that triggers assert()
is 35, or EAGAIN (Linux). This makes no sense. It's neither described
on the pthread_join
* Melchior FRANZ -- Monday 14 November 2005 22:29:
$ fgfs --aircraft=ufo --prop:/environment/params/metar-max-age-min=1
--log-level=warn
I forgot --enable-real-weather-fetch.
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Ralf Gerlich schrieb:
Erm, yes...working on the GRASS-HowTo for Scenery Designers ;-) Didn't
get far yet...
Cheers,
Ralf
Yes, would be a nice christmas present! :-) :-)
I stared work with FGSD and made some smaller corrections but it is not
possible to correct a bigger area with that tool
On Mon, 14 Nov 2005 16:42:24 +0100, Oliver wrote in message
[EMAIL PROTECTED]:
I suggest to remove the SF bay scenery in the corresponding 10x10
scenery file.
This allows us to place the SF bay, which comes allready with the base
package, in the main scenery folder like all the other 10x10
Let us know how you get on, or better, if you're still stuck, ask for
real-time help on the IRC channel. There has been a steady stream of such, I
I've got Flight Gear 0.9.8 running. I can't thank you enough! I
downloaded both RPMs from rpmfind, which I may have seen in passing
during a
Hi all,
It seems the Data/ directory is missing in the pre3 package, which
basically contains only Data/AI/ at the moment, and hence explains a
few people not able to use the nimitz carrier (Data/AI/nimitz_demo.xml),
and fgfs will simply terminate with a very vague message saying
terminate
69 matches
Mail list logo
