command are you using to start up
fgfs, and what are the contents of your .fgfsrc?
Previous times that stuff like this has happened, it's been because
people have set absurdly high values for things like visibility
in their .fgfsrc.
Thanks,
-c
.fgfsrc or system.fgfsrc
Same thing happened to me.
Jon
Jon Berndt
Coordinator,
JSBSim Project
http://jsbsim.sf.net
Enter BUG REPORTS at
http://sf.net/tracker/?atid=119399group_id=19399
Enter FEATURE REQUESTS at
http://sf.net/tracker/?atid=369399group_id=19399
world' quite quickly ... and I do not set FG_SCENERY.
There is also a command line option to point to the scenery tree so
rather than making code changes, you could just add an option to your
system.fgfsrc (or your ~/.fgfsrc for unix people with the same issue.)
Curt.
--
Curtis Olson Intelligent
Is there anything strange in your .fgfsrc or system.fgfsrc files?
D Luff writes:
I've just checked out a completely clean base, simgear and
flightgear, and it is still starting up with full left aileron and full down
elevator. Is there really no-one else seeing this?
The full down
that this is with the external viewpoint. The cockpit view looks
normal.
I keep my setup pretty clean (no .fgfsrc or mods to base package). RL
is keeping me very busy right now, so I wanted to mention this sooner
rather than later. If noone can reproduce this, let me know and I'll
try to find time
/altitude, so it would have to be limited
to things like the 3D model and input bindings.
Perhaps a cleaner solution would be to extend FlightGear to use
multiple root paths. For example, if I had
FG_ROOT=/usr/local/lib/FlightGear:$HOME/.fgfs/
then $HOME/.fgfsrc/Aircraft/dc3-yasim-set.xml could
Gents,
With the latest CVS (1400 EST 3/5/2002) on my Cygwin/Win2k system the
textures in mountainous areas seem to walk across the ground and appear
and disappear in a very strange manner. I am wondering if anyone else sees
this problem.
To demonstrate this problem I used the following .fgfsrc
. First, I think you can over-ride the
preferences.xml on the command line, write and refer to your own custom one,
and inside that selectively refer to the subfiles of the original.
Second, a read-only site-wide preferences.xml should be very minimalist
so that it isn't too difficult to use the .fgfsrc
it out, grab the latest
CVS of FlightGear and the base package, then type
fgfs --prop:/sim/rendering/dynamic-objects=true
If you want to enable randomly-placed scenery objects by default, just
add
--prop:/sim/rendering/dynamic-objects=true
to your $HOME/.fgfsrc.
Contributions of other
to consider putting --random-wind in your .fgfsrc if
you would like each flight to be interesting.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http
David Megginson writes:
I just checked in changed to fix the init-order problem for *-set.xml
files. My solution was blunt but effective. I simply parse all of
the system.fgfsrc, $HOME/.fgfsrc, and command-line options twice --
once before loading the *-set.xml file, to make sure
--- David Megginson [EMAIL PROTECTED] wrote:
The idea was that system.fgfsrc is system-wide, while .fgfsrc is
per-user. For Windows, perhaps we should look for fgfs.cfg in My
Documents or wherever (is there any concept of separate user
directories yet?).
$USERPROFILE on WinNT shold resolve
it for your joystick and put it
somewhere FlightGear can find it. Then something like this to your
$HOME/.fgfsrc file:
--config=/home/david/lib/fgfs/my-joystick.xml
That way, the file will always be loaded when FlightGear starts up.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http
the beast off
the runway without crashing _before_ take-off ? Is it possible ?
I dunno, did you try flying it? Does it?
I don't even manage to hold the plane upright until liftoff ;-)
Now I know why: I set --prop:/environment/turbulence-norm=1.0 in my
~/.fgfsrc and obviously this has impact
Jonathan Polley wrote:
Now that I have FlightGear linking, I have found another problem that
has cropped up recently (I'm not sure when, exactly). It seems as if
the 3D panel is always active. Since I always run FlightGear with the
--disable-panel in my .fgfsrc file, this causes problems
Jonathan Polley writes:
Now that I have FlightGear linking, I have found another problem that
has cropped up recently (I'm not sure when, exactly). It seems as if
the 3D panel is always active. Since I always run FlightGear with the
--disable-panel in my .fgfsrc file, this causes
in the /usr/local/bin directory to this binary.
FlightGear really doesn't care where you put things, as long as you
tell it where to find them.
In my ~/.fgfsrc I have:
--fg-root=/home/curt/projects/FlightGear-0.9
--fg-scenery=/stage/catalina3/Scenery-0.9.1
Regards,
Curt.
--
Curtis Olson IVLab
specify
something like this in your ~/.fgfsrc file:
--prop:/jsbsim/config/integrator=mytype
--prop:/jsbsim/config/logging=true
--prop:/jsbsim/config/atmosphere=mars
That would require _no_ action from the FlightGear side.
Erik
___
Flightgear-devel
)
consolewindow.Where is the output displayed?
The fgfsrc default browser seems to be Netscape but
I am using KExplorer - how to change the file entry if required?
I want to work on putting real dials in the TSR2
instead of the digital readouts - am I re-inventing the wheel?
Finally, using
by default now. It was on
before. Is it intended ?
-Fred
Hi Fred,
Just look in main.cxx where it sets:
fgSetBool(sim/sceneryloaded,false);
This line could probably just be removed (afik it'll default to false), then
if you set it true in your .fgfsrc file it won't pause the FDM
* Martin Spott -- Tuesday 17 August 2004 11:09:
In this context an idea comes to my mind: Would'nt it be useful to let
'metar' honour the respective parameters in a ~/.fgfsrc file (proxy
settings for example) in the same the way, 'fgfs' does !?
Useful?yes
Feasible? hmm
This would involve
On 12/12/04 at 7:52 PM Paul Surgeon wrote:
On Sunday, 12 December 2004 19:29, Paul Surgeon wrote:
What do people think about having a ~/.fgfs folder?
I need a place to be able to read and write user data.
.fgfsrc could also live in there too.
I personally think that if you can get fgfs
very quickly without having to worry
about keeping everyone else happy. If they don't like it they don't have to
use it.
2. It's dynamic (none of this static .fgfsrc file stuff that FG only reads
when starting)
The only thing now is to get one of the core developers to update the
interface
interpreter ...
fgfs --native-gui=socket,out,1,broadcast,5504,udp
You *shouldn't* need these for options included in your .fgfsrc file.
I'm not in a place where I can test if this actually works though ...
Tried it, and the shell punted..
This aircraft model is a BETA release
Durk Talsma wrote:
Hi,
I just ran into the following issue:
In my .fgfsrc I have specified
--fg-scenery=/home/durk/FlightGear-Scenery-0.9.5/
Which is a directory I had just deleted a few minutes earlier, because of an
upgrade to Scenery-0.9.[78].
As a result, FlightGear quit with a segmentaton
nodes
within this scope are invalid, too.
Can anyone also cause this segfault by using with an .fgfsrc containing
just one line
--airport=EDHI --aircraft=bo105 --enable-game-mode
?
Regards Ron
Gerhard Wesp schrieb:
On Fri, Feb 11, 2005 at 04:14:15PM +0100, Ron Lange wrote:
double v = vel
* Ron Lange -- Monday 14 February 2005 10:29:
Can anyone also cause this segfault by using with an .fgfsrc containing
just one line
--airport=EDHI --aircraft=bo105 --enable-game-mode
It issues two warnings:
Failed to find runway 28R at airport EDHI --aircraft=bo105 --enable-game-mode
two
property nodes within this scope are invalid, too.
Can anyone also cause this segfault by using with an .fgfsrc
containing just one line
--airport=EDHI --aircraft=bo105 --enable-game-mode
Ron,
Definitely you should put one option per line. The parser simply wasn't
designed to accept
of the problems.
I don't know if anything more has been done on this (I don't see
anything in the archive), but I can reproduce something very much like
this on linux.
snip
Hmm, this sounds familiar...
try --prop:/sim/rendering/use-display-list=false in your .fgfsrc
Simon
/visibility
/menubar
/sim
...
/PropertyList
or simply start fgfs with this option (or put it into ~/.fgfsrc):
--prop:/sim/menubar/visibility=0
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman
it for me, and it could be in ~/.fgfsrc instead).
m.
FG_HOME ... defined as $HOME/.fgfs/ here
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
into the problem. (Do you have anything weird in your
~/.fgfsrc or do you give additional options to getelev, all of which
are handed over to fgfs?)
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman
Le lundi 13 juin 2005 07:37 -0700, Andy Ross a crit :
Andy Ross a crit :
--prop:/sim/rendering/clouds3d-cache-size=4096
It should work but the program overload the data, only one way the
nasal way
That sounds like a bug to me. The command line should be overwriting
anything in the
Gerard wrote:
Melchior wrote:
Yes, and I was right: this file just doesn't exist! This is not an
fgfs message, but one of the operating system.
Not so Quick..
Oh do you remember i told you :
You can't really argue with a syscall result. The file isn't there.
Maybe there are some
* Ralf Gerlich -- Monday 13 June 2005 20:07:
Gerard Robin wrote:
open(/home/tux-le-boss/.fgfs/preferences.xml , [...]
^^
Did you see those blanks at the end of the filename? Are these actually
in the original report? Where could these
Curtis L. Olson wrote:
Have you played around with these properties (setable from the command
line, or ~/.fgfsrc file.)
--fov=35
--prop:/sim/view/config/heading-offset-deg=42
--prop:/sim/view/config/pitch-offset-deg=3
I should point out that we also have some capabilities for configuring
line or ~/.fgfsrc, too:
$ fgfs --prop:/sim/current-gui=1
But why not simply replace the old style with the new?
- the old style is faster -- two or three frames per second on my
archaic graphics card!
- in bright environments the old style may be better suited
- for hysterical raisins
I
/params/control-fdm-atmosphere=true
(Unfortunately, if you try to turn these properties on after the program
has started, it doesn't work.)
Alternatively, you can add the two switches to your $HOME/.fgfsrc,
or change the corresponding properties in $FG_ROOT/preferences.xml
This will allow you to enjoy
Title: Message
Hello
all,
I'm trying certain senarios
via waypoints and varying altitudes by using flightplan/.fgfsrc file. I
plan on implementing a data input change for route manger code to read a file
with my data, but in the mean time I was wondering if there's a reason why [EMAIL
), and anther
running the exterior view(and the FDM).
I really have no need to have the exterior view on the panel system.
Hi Bruce,
Try adding this option to your ~/.fgfsrc or the command line:
--prop:/sim/rendering/draw-otw=false
Curt.
begin:vcard
fn:Bruce Benneke
n:Benneke;Bruce
org:Benneke
the
second argument into her .fgfsrc so that she gets the right DC-3 model
automatically. Unfortunately, that means that she'll also get that
DC-3 model for the C-172, C-182, C-310, Harrier, and so on, since it
overrides the value in any of the *-set.xml files.
My proposed solution is to add
the different model:
fgfs --aircraft=dc3-yasim --prop:/sim/model/path=Aircraft/Models/dc3-usa.ac
That works, but it's annoying. She'll be tempted, then, to put the
second argument into her .fgfsrc so that she gets the right DC-3 model
automatically. Unfortunately, that means that she'll
for a real saitek owner to chime in here:))
Well, we thought we'd give it one more try and thus ran off and got the
plib cvs...
Reran fgjs and replaced the .fgfsrc file with that (although it looks
exactly the same as what was there before I started hacking on it).
Results: no change :-(.
Using
for ~/.fgfsrc
char* envp = ::getenv( HOME );
if ( envp != NULL ) {
config.set( envp );
config.append( .fgfsrc );
fgParseOptions(config.str());
}
#if defined( unix ) || defined( __CYGWIN__ )
// Check for ~/.fgfsrc.hostname
gethostname( name, 256 );
config.concat
Make a copy of the file, then edit it for your joystick and put it
somewhere FlightGear can find it. Then something like this to your
$HOME/.fgfsrc file:
Ok, the attached file is my work. I simply copy and paste the area of the
throttle and rename all throttle to rudder. but it doesn't work
Make a copy of the file, then edit it for your joystick and put it
somewhere FlightGear can find it. Then something like this to your
$HOME/.fgfsrc file:
Ok, the attached file is my work. I simply copy and paste the area of the
throttle and rename all throttle to rudder. but it doesn't work
I would prefer to distribute the .app version, but I need someone to verify it for me.
Just because it works for me does not mean that I created it properly. Come on Mac
users, give it a try! :)
When I use FlightGear, I have no choice but to use the .fgfsrc file. Unfortunately,
because OS X
the reading and writing?
If so that could make things rather complex and it would have to be thread
safe too.
I'm not opposed to using a ~/.fgfs/ directory. Perhaps we should have a
~/.fgfs/settings.xml file instead of a ~/.fgfsrc, if we wanted to make
this writable, then perhaps the first time
-12-08 at 07:39, Jon S. Berndt wrote:
Just did a fresh cvs update -dP on the base directory and still get this
message:
Error loading aircraft file: Failed to open file
at /home/Jon/FlightGear/Aircraft/c172-set.xml
Check for and remove --fdm or --aircraft options in your
.fgfsrc
property in your .fgfsrc) -- we'll try to provide
reasonable default values in c172-set.xml once current work
stabilizes, but you can choose different values for your own preferred
flight conditions (econo-cruise, speed daemon, low flyer, etc.).
For the Cessna 182 and Cessna 310, there is a rudder
* David Megginson -- Thursday 21 February 2002 15:26:
[...]
This is a little ugly, but ordinary users should never have to see
it. Now, the user can put
-prop:/config/aircraft/dc3-dpm/sim/model/path=Models/dc3-usa.ac
in her .fgfsrc and get a different 3D model for the DC-3 without
does
c172-yasim does not
c310-yasim does
dc3-yasim does not
Is this a 'feature' or is this a bug ? This 'feature' is rather new to me,
so I'm wondering heavily. These are the parameters I'm running FlightGear
with:
foehn: 16:29:36 ~ grep -v ^# .fgfsrc | grep -v ^\$
--fg-root=/home/mas/src/FlightGear
/
then $HOME/.fgfsrc/Aircraft/dc3-yasim-set.xml could contain properties
overriding some or all default values from
/usr/local/lib/FlightGear/Aircraft/dc3-yasim-set.xml.
This same question occured to me when working on the panel stuff. It seems as
though the -set.xml files are used
and disappear in a very strange manner. I am wondering if anyone else sees
this problem.
To demonstrate this problem I used the following .fgfsrc:
--fdm=magic
--disable-clouds
--disable-panel
--disable-sound
--geometry=1024x768
--in-air
--lat=35.88
--lon=-113.7
--altitude=9200
--heading
to pan the view. That
worked well for me (I keep it as a local mod loaded from my .fgfsrc).
I'm appending the bindings to the end of this message.
I did a lot of autopilot assist and it's very interesting. It does
give you a much better feeling of being inside an aircraft.
Portions
, consider rebinding the arrow keys to pan the view. That
worked well for me (I keep it as a local mod loaded from my .fgfsrc).
I'm appending the bindings to the end of this message.
I agree wholeheartedly. The most intuitive method for controling view
direction is a pan left/right/up/down control
provide the contents of my ~/.fgfsrc, but I don't believe this has
anything to do with it:
--aircraft=a4-yasim
--airport-id=KOAK
--start-date-lat=2002:04:11:11:11:11
--enable-fuel-freeze
--wind=270@10:15
--disable-splash-screen
--disable-intro-music
--control=mouse
--enable-auto-coordination
--disable
Victoria Welch [EMAIL PROTECTED] said:
Hi All,
Just wondering if anyone else uses this stick successfully?
It works perfectly here under windoz but after *hours* of changing the
.fgfsrc and starting and stopping fg for each change, I am getting a
little discouraged.
I'm
and set up
a file joysticks.xml for you. I used to use .fgfsrc, but found it a
lot easier to switch joysticks using joysticks.xml.
Regards,
Dave
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
/mailman/listinfo/flightgear-devel
Norman,
Thanks for the hints. Will try addr2line shortly. I had set the
fg-root in my .fgfsrc, and it was being used throughout the startup. I
also had an entry for the scenery directory, and hadn't edited it to
match, but fixing that does not change
who always specify the aircraft anyway (often in $HOME/.fgfsrc), but
it will make a big difference for what new users see the first time
they start up.
David,
Thanks for doing this. I have one minor nit (which is probably an
easy thing for a flatlander to miss.) :-) I don't see any way
it by
setting the
/instrumentation/attitude-indicator/config/tumble-flag
property to false in your $HOME/.fgfsrc.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL
2003 00:59:
you said 'personal preferences.xml'
$ fgfs --config=/your/personal/preferences.xml
or
$ cat ~/.fgfsrc
--config=/your/personal/preferences.xml
$ fgfs
(mine is called ~/.fgfs/preferences.xml. I have some other
personal fgfs config stuff in the hidden ~/.fgfs/ dir
.) But this is at
least several hundred machines and even more users that can run
flightgear out of the same installation tree (which is obviously read
only to all but me and the sys admins.)
In this case ~/.fgfsrc files and environment variables are very handy
if anyone wants to make local customizations.
Regards
and failed to simulate the first shot with the command line
fgfs --start-date-gmt=2003:07:12:16:04:13 --airport=EGTP --fog-disable
--disable-clouds --disable-clouds3
I even removed my ~/.fgfsrc but I still get a dramatically clouded sky. I
seem to remember detailed weather startup parameters being
Melchior FRANZ wrote:
* Martin Spott -- Tuesday 17 August 2004 11:09:
In this context an idea comes to my mind: Would'nt it be useful to let
'metar' honour the respective parameters in a ~/.fgfsrc file (proxy
settings for example) in the same the way, 'fgfs' does !?
Useful?yes
Unix-like and doesn't require an fgfs config.
You know, fgrun notoriously overwrites ~/.fgfsrc ... which I consider a bug,
btw. :-]
And for the MICROS~1 people:
http://www.google.com/search?q=windows+set+environment+variables
(These variables don't need to be set in *.BAT files, they can also
be mounted RW.
IMO this should be discussed very carefully before proceeding. What
data do we want to write out? What section of the code will do the writing.
I'm not opposed to using a ~/.fgfs/ directory. Perhaps we should have a
~/.fgfs/settings.xml file instead of a ~/.fgfsrc, if we wanted
--native-gui=socket,out,1,broadcast,5504,udp
You *shouldn't* need these for options included in your .fgfsrc file.
I'm not in a place where I can test if this actually works though ...
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu
, and that seems to me, as it should be ... ;=))
Perhaps the only counter, is that system.fgfsrc is read twice,
but so are others, like .fgfsrc, for other (local) options ...
or system.fgfsrc should .nt. be used for 'aircraft' ?
It certainly paves the way for fgrun to simply write the
system.fgfsrc
,
but so are others, like .fgfsrc, for other (local) options ...
or system.fgfsrc should .nt. be used for 'aircraft' ?
Well, reading this piece of code, I don't see how it could work. see below :
Index: fg_init.cxx
===
RCS file: /var/cvs
Melchior FRANZ schrieb:
* Ron Lange -- Monday 14 February 2005 10:29:
Can anyone also cause this segfault by using with an .fgfsrc containing
just one line
--airport=EDHI --aircraft=bo105 --enable-game-mode
It issues two warnings:
Failed to find runway 28R at airport EDHI --aircraft=bo105
is good.
I have searched what could be the cause of dysfunctions.
Nothing found.
I deactivated every parameters in .fgfs and .fgfsrc
I entered the path of FG_ROOT (export .)
I gave the full path for the file
I have the last
:/environment/params/real-world-weather-fetch=true
+can be shortened to --enable-real-weather-fetch, but this doesn't
+include the second property setting option.
+
+Alternatively, you can add the two switches to your $HOME/.fgfsrc,
+or change the corresponding properties in $FG_ROOT/preferences.xml
On Wednesday 09 Nov 2005 22:02, Craig E. Staples wrote:
Hello all,
I'm trying certain senarios via waypoints and varying
altitudes by using flightplan/.fgfsrc file. I plan on
implementing a data input change for route manger code to read
a file with my data, but in the mean time I
or ~./flightgear/
When using the latter one, we could also start to put the .fgfsrc config file
into ~./flightgear/
The preferenced.xml file should also belong there, because it is user specific
and the user should allways be able to edit it.
A system wide global installation should put the scenery
Dave Perry wrote:
After noting Sid Boyce note concerning freeglut on the users list
where ~/.fgfsrc was the issue, I renamed that file and fgfs worked.
Then I checked which option in fgrun would cause the freeglut abort.
The only problem option I found is
--enable-clouds3d
Same result from
for root: /home/jimg/.fgfsrc
fg_root = /usr/local/src/X11/fgfsbase
Segmentation fault (core dumped)
Hmmm, this looks like you are dying in the property manager code some
how. Do you have the latest cvs version of the base package? Perhaps
a config file there got corrupted
0.7.9
Scanning for root: command line
Scanning for root: /home/jimg/.fgfsrc
fg_root = /usr/local/src/X11/fgfsbase
Segmentation fault (core dumped)
Hmmm, this looks like you are dying in the property manager code some
how. Do you have the latest cvs
My package actually does not use a .fgfsrc file. It passes the flags
straight to fgfs.
And I don't understand resource forks either. And have never worked with them.
I couldn't get fgrun to compile on OSX and so have started to write
one that's OS X native using Cocoa and AppleScript
wondering if I may not be doing this correctly.
The linux FG is on IP 192.168.0.10 and the cygwin is on 192.168.0.69 ..
Do I have the rx and tx addresses switched around?
Here is what I have in my .fgfsrc file on the linux box:
(similar lines on cygwin box)
### for NetWork ###
--multiplay=out
you specify the same port for both FlightGear and
TerraSync. Feel free to put this options in your ~/.fgfsrc (or
system.fgfsrc) so you don't need to type them every time. Notice
that the --fg-scenery= option can take a set of scenery search
paths.
2. Start terrasync (included
to localhost 5500.
I don't see anything in the (telnet or fg) console window. Where is the
output displayed?
The fgfsrc default browser seems to be Netscape but I am using KExplorer
- how to change the file entry if required?
I want to work on putting real dials in the TSR2 instead
am
not sure I understand what they mean offhand. I'm guessing I'm getting
one from each of the identical error messages in that area of the code.
I can reproduce the last message by pressing escape to quit, and then
hitting Cancel.
my .fgfsrc:
--airport=KBJC
--disable-clouds
--visibility-miles
the
shell history, where I hadn't specified this option. Because I had made sure
that I had temporarily removed .fgfsrc file, I assumed that it would fail to
find any base packages at all if I didn't specify the fg-root path, because I
have installed the regular (CVS) base package in a non-default
a zigzag path with the pedals, it shakes it free and the compass
eventually settles to a proper reading. Just that I've never seen an
oil-damped unit bind that way in real life. The mounting needs a bit
more freedom.
While tracing the compass problem, I started using my usual .fgfsrc
file
for .fgfsrc.hostname file
3. if empty, try HOME .fgfsrc };
4. if still empty - add my patch - check for $fg_root/system.fgfsrc );
ending with, as it does at present, unchanged -
if NOT ( aircraft.empty() ) add it fgSetString(/sim/aircraft,...
else complain/explain No user specified aircraft, using
Curtis L. Olson wrote:
Have you played around with these properties (setable from the command
line, or ~/.fgfsrc file.)
--fov=35
--prop:/sim/view/config/heading-offset-deg=42
--prop:/sim/view/config/pitch-offset-deg=3
I *think* you can adjust these properties in real time if you need
(or in our case, by setting the
/controls/*-trim property in your .fgfsrc) -- we'll try to provide
reasonable default values in c172-set.xml once current work
stabilizes, but you can choose different values for your own preferred
flight conditions (econo-cruise, speed daemon, low flyer, etc
with a GeForce2MX.
Just tried the c310, triggered by comments on its progress, and I fully
agree. Did some tweaking to my .fgfsrc to handle the dual engines, and
everything looked good at first. An extract of said file is below (cut a
bit to save space). Further trials showed an interaction between
(failed) Nvidia card is replaced with a GeForce2MX.
Just tried the c310, triggered by comments on its progress, and I fully
agree. Did some tweaking to my .fgfsrc to handle the dual engines, and
everything looked good at first. An extract of said file is below (cut a
bit to save space
As we all know the cvs base ONLY has W130N30, with
only W122N37 and W123N37 - some 149 files, including the
few cvs generated folders\files - while the CD-ROM scenery
contains nearly 62,000 files.
BUT a trial of commenting out this scenery path change in
.fgfsrc produced EXACTLY the same results
Hello Jim,
Thanks for the response!
On Fri, 2002-07-12 at 11:32, Jim Wilson wrote:
Victoria Welch [EMAIL PROTECTED] said:
Hi All,
Just wondering if anyone else uses this stick successfully?
It works perfectly here under windoz but after *hours* of changing the
.fgfsrc
be
very near to a working joystick. I would be glad to go ahead and set up
a file joysticks.xml for you. I used to use .fgfsrc, but found it a
lot easier to switch joysticks using joysticks.xml.
Sigh, I'd like to think this is going to work. Part of the problem is
that I have so many
interface in my
.fgfsrc. Commenting it out allowed the program to start normally.
I don't know if this is apropos, but you never can tell.
On Wednesday 23 October 2002 11:50 pm, Michael Selig wrote:
At 10/23/02, Curtis Olson wrote:
Michael Selig writes:
I am still getting the same segfault w
in /usr/local/FlightGear)
2) Tell FlightGear where to find the base package
i.e. put --fg-root=/usr/local/src/fgfsbase in your ~/.fgfsrc file.
run fgfs
Now, let's say a couple of days go by, and I want to get the latest CVS.
cd /usr/local/source/FlightGear (not /usr/local/lib/FlightGear?)
cvs
. Enclosed is the stacktrace
from gdb.
I've compiled FlightGear with thread support and I used the following .fgfsrc
file:
--airport=EHLE
--time-match-local
--prop:/environment/params/real-world-weather-fetch=true
--fg-scenery=/home/durk/FlightGear-Scenery/
--nmea=socket,out,0.5,10.0.0.4,5500,udp
Double-clicking the icon isn't the problem. In many cases, getting the
.fgfsrc file properly installed was the problem. For my next release,
I was going to include a python script that would set up the file and
modify the default resource file. Many Mac users that subscribe to the
Users
reported clear, and
the startup of FG was normal. With no sky report, FG showed the
default scattered condition. Still wonder why the missing field seemed
to confuse the initial conditions, I tried it back and forth at least
5 times and the startup error followed the .fgfsrc edits.
--
Bill
frustum approximately?
Have you played around with these properties (setable from the command
line, or ~/.fgfsrc file.)
--fov=35
--prop:/sim/view/config/heading-offset-deg=42
--prop:/sim/view/config/pitch-offset-deg=3
I *think* you can adjust these properties in real time if you need
101 - 200 of 211 matches
Mail list logo
