Roy Vegard Ovesen wrote:
I've slapped together a short document on controller tuning.
[ snip ]
Thanks Roy!
For everyone: I've integrated this into a larger document which attempts to
explain the basic ideas behind control theory and then describes the
specific PID algorithm we have implimented
I'm tempted to commit my autopilot changes to cvs.
Here's what I have done so far.
- I've implimented Roy's suggested PID algorithm. Compared to what we had,
this algorithm is better behaved, is much more configurable, and much more
tunable. It can be made to do a much better job of easing
Jon Berndt wrote:
Does this make it any easier to bypass the FlightGear autopilot (and perhaps
soon-to-exist) FCS system, so the FDM could provide this functionality, if
desired - perhaps by simply not including an autopilot/FCS file or
definition through your new method? This is very important to
Jon Berndt wrote:
Yes this is where it gets complicated. There are modes that are obviously
relevant to mere flight dynamics, such as attitude hold, heading select,
wings level, terrain following, etc. -- and even these use *sensor* inputs
as opposed to actual FDM aircraft state data. The other
David Culp wrote:
Comments? Any objections to committing my updates?
It looks great, and I think the sooner it gets commited the better, so we'll
have plenty of time to work with it before 0.9.4.
I already have a wish list :) mach hold, and vertical speed hold.
Ok, it's been at least an hour
Norman Vine wrote:
Hmm... 1 hour 08 minutes on a weekend
Was any discussion really wanted :-)
Being a volunteer and doing this on weekends and evenings, I've got to move
quickly when I do get the chance. I've been working hard on this and
trying to factor in comments and suggestions made
Frederic Bouvier wrote:
Small glitch at run time :
route = 0D7673D8
Failed to load autopilot configuration:
fgfsbase/Aircraft/Generic/generic-autopilot.xml
CVS Updated and no generic-autopilot.xml
Gaahhh! I swear I added that file. Ok, it's there now. Sorry about that.
Curt.
--
Curtis Olson
Martin Spott wrote:
Curtis L. Olson [EMAIL PROTECTED] wrote:
Occasionally, a tile can reference 3d models that require calling
ssgLoadXYZ() ... things like building, bridges, etc. When the threaded
tile loader runs into any of these, it will push the object onto a separate
model loading
Andy Ross wrote:
[EMAIL PROTECTED] wrote:
Mail transaction failed. Partial message is available.
Oh no! Curt's infected.
cough cough
We have to kill him now.
Is that Oregon's answer to affordable universal health coverage? :-)
Curt.
--
Curtis Olson HumanFIRST Program
David Luff wrote:
There seems to be a problem with the fogging on my machine (Linux, NVidia card). When the sun is in, or just out of, the field of view, the fog disappears and visibility is perfect. This is most easily seen by starting at dawn or dusk, and with a low visibility (eg 5000), climb
Roy Vegard Ovesen wrote:
I don't think this should be part of the PID algorithm. I think we
should use your hack and apply it to the setpoint to the v/s or pitch.
This means that we need some sort of if ... then functionality. I just
started looking at Nasal, and I think that could be used for
David Luff wrote:
Could someone please clarify my understanding of the threaded tile loader?
I'll take a stab at it. :-)
My initial pre-conception before reading the code was that the loader
thread would simply load the data from disk, and pass off a memory buffer
containing an image of the disk
Ok, I'm abusing my powers here to ask a really [OT] question. If anyone
objects, you definitely wouldn't be out of line. But it's easier to ask
forgiveness than permission, right? :-)
I have some really old, as in ancient ventura publishing files that I'd be
interesting at cracking open and
Innis Cunningham wrote:
This is what I dont understand what is wrong with the current system
which can do heading,V/S,wing leveler,vor/loc(nav),approach,and
autothrottle
are these not accurate enough?.
Also how much more computing power will be required for what ever extra
detail may be
Roy Vegard Ovesen wrote:
On Mon, 26 Jan 2004 13:13:44 -, Richard Bytheway
[EMAIL PROTECTED] wrote:
That would be the responsibility of the autopilot designer. If he/she
designed a control structure that used two separate
controllers that acted
on the ailerons, that would be his/her problem.
Jim Wilson wrote:
Just a thought :-)
I got lectured once in a job interview (that obviously did not go well for
me.) The interviewer didn't like my answer on the future of computer
security. He asserted that in 6 months (this was 10 years ago) that all
security problems would be solved
Cameron Moore wrote:
Yes, we can actually. Just filter out this in Mailman:
^X-Mailer:.*Outlook
Problem solved. ;-P
gritting teeth
Must fight ... the ... urge ... to ...
/gritting teeth
Disclaimer. We love our outlook users, just not the virus and security
problems that seem to plague
Jon Berndt wrote:
My understanding is that they will be doing a lot of thrust
vectoring ... lots of research is/has been done in that area.
Curt.
No. This paper describes tests on a B-747, C-17, and MD-11 using propulsion
only:
http://www.dfrc.nasa.gov/DTRS/1999/PDF/H-2331.pdf
Differential
David Luff wrote:
tilemgr.cxx contains the following block of code (lines 178 - 181):
xrange = (int)(vis / tile_width) + 1;
yrange = (int)(vis / tile_height) + 1;
if ( xrange 1 ) { xrange /= 1; }
if ( yrange 1 ) { yrange = 1; }
It looks to me like there might be a stray / sign
Erik Hofman wrote:
Well, here is a standard that *you* can actually try to influence ...
BTW. XML makes extending the existent layout without influencing the
previous versions possible by nature.
All that would need to happen is for someon to write a plib reader/writer
for the xgl format and
Snyder Adam D Civ AFRL/VACD wrote:
Not really, I just need to find a way to clean-up when I am finished.
Here's one option. If you put all your code inside a class, then you
should be able to put your clean up stuff into the class destructor. That
should automatically be called when the
Martin Spott wrote:
Erik Hofman [EMAIL PROTECTED] wrote:
I just read about an XML based 3d file format:
http://www.xglspec.org/
We might want to keep an eye on that.
I must admit that I didn't understand the advantage over existing 3D
object/scene description file formats,
I wonder if this is
Roy Vegard Ovesen wrote:
And I firmly believe that we _should_ use the instrument values because
in my mind using /position/... and /velocities/... would be cheating,
theese perfect values are _not_ available in the real world.
I definitely agree. We should have instrument values well modeled
David Culp wrote:
This thread is scaring me. I hope we aren't deciding to hard-wire the
autoflight inputs from panel instrument output?
The input choice will be strictly optional, right?
Figures, I just finished screwing the cowl back on ...
The whole point of defining the autopilot via xml is
Lee Elliott wrote:
I've been giving quite a bit of thought to look-ahead algorithms for terrain
following. The most straight forward way would be to take a number of
look-ahead samples each frame, and simply take the highest point as the
target alt.
Taking a lot of samples each frame can't be
Roy Vegard Ovesen wrote:
Let me share my thoughts about the autopilot:
* I would like to see the autopilot move from c++ code into the
instrument configuration xml-files.
This is my general plan. Right now I have the autopilot config in a
separate .xml file
* The autopilot should get input
David Culp wrote:
On Wednesday 14 January 2004 08:29 am, Curtis L. Olson wrote:
FlightGear has been offered free .org booth space and a possible speaker
slot at the Linux User Developer Expo 2004. This is Oct 20-21 at the
Olympia Exhibition Centre in London, UK. You don't necessarily need
Lee Elliott wrote:
Hello All,
I'd like to propose a change to the way that the Terrain Following (TF) agl
value is set and controlled.
Currently, when TF mode is selected, the current a/c agl value is used but I'd
like to change this so that this value is set, and can be changed via the
Tim Jelliffe wrote:
Hi guys,
I have a general question regarding the creation of a model. I have been
working on creating a model of a Learjet 55, using CATIA V5. This is
mainly because I used this during my degree and am basically familiar
with it. I am also determined to have a model which
For any of you interested in doing IRC, Nic Fischer has given us a channel
on his IRC server. Just connect up to irc.flightgear.org and join the
#flightgear channel.
Regards,
Curt.
--
Curtis Olson Intelligent Vehicles Lab FlightGear Project
Twin Cities[EMAIL PROTECTED]
Arnt Karlsen wrote:
On Mon, 19 Jan 2004 15:21:24 -0600,
Curtis L. Olson [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
For any of you interested in doing IRC, Nic Fischer has given us a
channel on his IRC server. Just connect up to irc.flightgear.org and
join the #flightgear channel
Christopher S Horler wrote:
I don't use many cvs commands, but one I use a fair bit is log. However
I've never figured out how to make it only display the last e.g. 5 log
entries or from a certain date... if it doesn't do it it should...
I don't know if there is a command to display the last 5
FlightGear has been offered free .org booth space and a possible speaker
slot at the Linux User Developer Expo 2004. This is Oct 20-21 at the
Olympia Exhibition Centre in London, UK. You don't necessarily need to be
a developer to help with the booth, but a moderate working knowledge of
Martin Spott wrote:
Curtis L. Olson [EMAIL PROTECTED] wrote:
FlightGear has been offered free .org booth space and a possible speaker
slot at the Linux User Developer Expo 2004. This is Oct 20-21 at the
Olympia Exhibition Centre in London, UK. You don't necessarily need to be
a developer
David Luff wrote:
OK, that's a definate now :-)
Ok, so far here is what I have:
- Al West can definitely be there.
- David Luff can definitely be there.
- Jon Stockhill probably will be at the show and probably can help with the
booth.
- Matthew Law thinks he can be there but needs to clear it
Innis Cunningham wrote:
I guess this question is for David Megginson or Erik Hofman.
I would like to have the ability to turn instruments on and
off in the 2D panel XML file is this already possible.If so how?.
If not would it be a big job to add it to the panel XML code.
Thanks for any idea's.
Andy Ross wrote:
So which wheels get controlled by the parking brake on the bo105,
harrier, or 747? :)
This same subject just came up a few days ago. The real bug is that
we're trying to associate brake controls with individual wheels, which
is just wrong. The only standard for brakes in
John Wojnaroski wrote:
Walking thru some code yesterday, I noticed the following:
In tilemgr.cxx at lines 319 and 321 there are two entries for adding taxi
lights. Is that what is intended?
Yeah you are right, there is a problem there. I have checked in a fix to CVS.
Curt.
--
Curtis Olson
Vikki,
I don't see -lglut listed on the link command line. You probably want to
rerun the configure script and make sure that the glut test there succeeds.
If not, then look in your config.log to see exactly what failed.
Regards,
Curt.
Victoria Welch wrote:
Hi Folks,
A couple days or so
Hof Markus wrote:
nice layout... is this a faked frame rate? ;-)
if not pretty good. how come?
Probably because Eric runs on sgi hardware. :-)
Curt.
--
Curtis Olson Intelligent Vehicles Lab FlightGear Project
Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED]
Minnesota
for the response. I went through config log (~=2500 lines :)
and am no more enlightended - see below :-(.
On Sunday 11 January 2004 14:14, Curtis L. Olson wrote:
Vikki,
I don't see -lglut listed on the link command line. You probably
want to rerun the configure script and make sure
Victoria Welch wrote:
I'm thinking I want to get into building panels for FG aircraft.
Either I am missing it or the tools for the job are vi, gimp, an
XML reference and all the FG header files ?!?
Any comments or suggestions appreciated!
I'll chime in with a couple comments.
First off,
Lee Elliott wrote:
Heh - it seem to me that most of the kids here (UK) just speak pretty bad
english;)
That depends on how you look at it. You could say that english is whatever
english speaking people are speaking these days. Or you could flip that
around and come up with some defined
Frederic BOUVIER wrote:
Thanks, glad to see you like it and it doesn't kill all the framerate.
For people that are not following CVS updates, check out :
http://perso.wanadoo.fr/frbouvi/flightsim/sanfran.htm
The lights are brighter in FG than on jpeg but you will have an idea.
That remind me that
David Megginson wrote:
Actually, if you're approaching a runway from about 90 degrees, it's the
taxiway lights that you can see -- the runway lights are invisible until
you're right overhead.
Yes, it's a subtle effect and you may not notice it unless you are
looking for it specifically, but all
We probably should steer away from the political discussion stuff (on this
forum) before we forget we are working on an open source simulator. :-)
Curt.
Christian Mayer wrote:
David Megginson schrieb:
JD Fenech wrote:
This is pretty sad.
It's times like this when I start to consider
Frederic BOUVIER writes:
Hi Curt,
the 'Contributors' link give 404. The link 'thanks.html' should be
'thanks.shtml'.
Thanks for catching this ...
Curt.
--
Curtis Olson HumanFIRST Program FlightGear Project
Twin Citiescurt 'at' me.umn.edu curt 'at'
Seamus Thomas Carroll writes:
I am playing with the autopilot and maintaining an altitidue above sea
level works great. Is there a method for maintaining an elevation above
the ground?
Ctrl-t will toggle a mode that attempts to maintain the current
altitude above ground. The algorithm is
Jim Wilson writes:
Andy Ross [EMAIL PROTECTED] said:
Jim Wilson wrote:
Note, I'm suggesting adding Andy's work to plib as an alternative
optimizer function, not a replacement for the current code.
No need for this. They produce identical results if you set the sharp
angle to 180
Gerhard,
Try this:
fgfs --aircraft=c172-610x-jsbsim
Intentionally, the c172-610x doesn't have an internal fdm definition
so it only works if the fdm information is coming from some external
source. To say it another way, the c172-610x *allows* you to specify
an external fdm source which is
Gerhard Wesp writes:
fgfs --aircraft=c172-610x-jsbsim
Already tried this on the Windows version, didn't work too.
Strange, it works for me here.
I've now just installed the Linux Debian packages (0.9.3) by Ove
Kaaven. On this platform, I get:
debian ~% fgfs
You should also check *very* carefully to make sure you don't have a
stray packaged copy of plib installed on your system somewhere. If
that was built with a different version of the compiler (very
plausible) then you would see errors similar to what you are
reporting.
Regards,
Curt.
Josh
Josh Babcock writes:
Actually, I think that I nuked the base makefile by unzipping the patch
in that directory. That brings me back to the original problem, which
is that I can't log into the CVS repository. I guess I'll just keep
trying. I tried applying the patches to the regular
Victoria Welch writes:
I've been burried here lately and haven't had a chance to try
someplace else yet, but is there no glideslope on the ils there or
do I have a problem? The glide slope indicator never uncages -
just stays centered (c172, C310).
The glide slope should be working.
Curtis L. Olson writes:
I did some work this evening in simgear/flightgear to track some
additional vasi positional information so that I can then compute the
angle and correct color. This is a first stab and the result is a
gross simplification of what really happens. There are some things
David, (Andy?)
It appears that in the latest cvs, we have lost the ability to control
the engines independently. Previously you could type Shift-1
Shift-2 Shift-3 ... etc. to select an engine. Then '{' and '}'
would select the magnetos. Finally, space bar would kick in the
starter motor for as
Andy Ross writes:
Curtis L. Olson wrote:
David, (Andy?)
It appears that in the latest cvs, we have lost the ability to control
the engines independently.
This one is mine. The recent Nasal stuff contains a rework of the
engine handling to allow for arbitrary numbers of engines
Jon S Berndt writes:
On Mon, 29 Dec 2003 15:49:30 -0600
Curtis L. Olson [EMAIL PROTECTED] wrote:
David, (Andy?)
It appears that in the latest cvs, we have lost the ability to control
the engines independently. Previously you could type Shift-1
Shift-2 Shift-3 ... etc. to select
Andy Ross writes:
Curtis L. Olson wrote:
David, (Andy?)
It appears that in the latest cvs, we have lost the ability to control
the engines independently.
This one is mine. The recent Nasal stuff contains a rework of the
engine handling to allow for arbitrary numbers of engines
Andy Ross writes:
Curtis L. Olson wrote:
David, (Andy?)
It appears that in the latest cvs, we have lost the ability to control
the engines independently.
This one is mine. The recent Nasal stuff contains a rework of the
engine handling to allow for arbitrary numbers of engines
Andy Ross writes:
Sure, there's a print() function which uses SG_LOG; for exactly this
purpose. There's even a fancy dump() method on a property node that
you can use to dump a property tree to the console.
Ok, thanks, I eventually found it. Quite useful, thanks. :-)
It turns out to be a
Pablo J. Rogina writes:
I was following the FG evolution since a long time, and I´m now willing to
to get involved to Flightgear. I think is quite a project where I´m to be
able to merge two of my hobbies: aviation and computing.
In order to contribute, I've selected to provide FG with the
Hoyt A. Fleming writes:
A month or so ago I noticed that the VASI lights vary based upon the pitch
of the aircraft.
This is a bug (or implimentation limitation) or whatever you want to
call it. It's high on the todo list to be fixed.
Over the holiday break, I noticed that the terrain shadows
Originally I tried to leverage an environment mapping trick to
impliment the VASI. However, my understanding of how this work was
not quite right, nor was the understanding of the person who suggested
this trick in the first place. The result is that the VASI is
dependent on the view direction,
Ok, should be fixed ...
[EMAIL PROTECTED] writes:
Am Samstag, 27. Dezember 2003 15:55 schrieb Jacek:
I have just tried to update from cvs:
cvs update: Updating simgear/compatibility
cvs update: Updating simgear/compatibility/MIPSpro721
cvs update: failed to create lock directory
Erik Hofman writes:
Curtis L. Olson wrote:
Ok, should be fixed ...
(/var/cvs/SimGear-0.3/SimGear/simgear/compatibility/MIPSpro721/#cvs.lock):
Permission denied
Do you have any idea what is causing these problems?
As far as I can tell everything went smooth.
When new directories
Merry Christmas from Minnesota.
I just received this so I thought I'd pass it along in case other's
hadn't seen it yet ...
Curt.
--
Curtis Olson HumanFIRST Program FlightGear Project
Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org
Minnesota
Hi Martin,
Martin Spott writes:
Especially the mess with NVidia's drivers is the manufacturer's fault.
ATI at least _tries_ to conform with the standards proposed by the DRI.
With ATI you can copy the DRI driver module and the kernel module
(after tweaking the build script) to the appropriate
Martin writes:
It became sort of a hobby to collect used Unix workstations. I have
an Octane with MXI graphics and TRAM as workplace at home, but this
machine (only 195 MHz) turned out not being able to keep up with
recent development. Its CPU is simply too slow and can't cope with
all the
Martin Spott writes:
I never owned an NVidia card, so I can't compare performance. Maybe
someone else has the opportunity to do that: Currently I have a
Radeon7500 plugged into a Pentium3/600 (I believe this one is still
running at 66 MHz external clock) with standard SuSE-9.0 XFree (built
Martin Spott writes:
Melchior FRANZ [EMAIL PROTECTED] wrote:
* Martin Spott -- Sunday 21 December 2003 00:07:
I tend to include OpenSource drivers only, no proprietary stuff.
I understand, but then the whole effort is pretty useless. There are
too many nVidia card users, and no open
Martin Spott writes:
Jon Stockill [EMAIL PROTECTED] wrote:
And the open source drivers don't support some of the newer ATI cards.
Sorry, why do you buy cards that are not supported by OpenSource
drivers ? You are developing OpenSource software, why don't you take
care of that. I can't
Martin Spott writes:
Not many, but on the other hand you won't have much trouble with the
BIOS when you think about a standalone FlightGear CD. Dealing with a
bunch of different kernel modules for autodetecting different vendors'
cards might prove to end in a huge mess. This _is_ very
Alex Perry writes:
From: Martin Spott [EMAIL PROTECTED]
Jon Stockill [EMAIL PROTECTED] wrote:
And the open source drivers don't support some of the newer ATI cards.
Sorry, why do you buy cards that are not supported by OpenSource
drivers ? You are developing OpenSource software, why
If anyone is interested in external scripting of FlightGear, I've
added another quick example to $fgsrc/scripts/perl/examples/
The reset.pl script will reset FlightGear to a particular
airport/runway at a fixed interval (i.e. every 5 minutes.) It also
sets the time of day to noon and makes sure
Alan King writes:
Rudder pedals. Been a while since I was at the controls in a Cessna
etc, how much control throw is normal? With a one foot seperation
between the pedals 4 seems like a lot, maybe too much. Currently have
2 in and 2 out for the 4 total, but can easily shorten it up,
Alan King writes:
Yes it is. But the control feedback in the simulator EXACTLY
matching real life is not critical. For that matter a Cessna rudder
probably doesn't exactly match a P-51 rudder either, but I have no
doubts that learning rudder on said Cessna prepares you for 80 or 90
Andy,
Why don't we go ahead and commit one of these since both sound a lot
better than what we have now. Then we could do some timing tests and
see if we need to consider trading precision for faster performance.
Regards,
Curt.
Andy Ross writes:
Norman Vine wrote:
Yes, this was written
Norman Vine writes:
http://www.boston.com/news/galleries/2003/domeplane/01.htm
Nice ... :-)
Curt.
--
Curtis Olson HumanFIRST Program FlightGear Project
Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org
Minnesota http://www.flightgear.org/~curt
Andy Ross writes:
As always, everything seems quite 'trivial' to those who haven't
actually tried to do it. Hurry up and build a running robot too
while you're at it..
Plonk. Does anyone with a real clue have an answer for this?
Sorry, not me. I was waiting until after I get finished
Kim Komando has FlightGear listed as her kool site of the day.
http://www.komando.com/
Klick on Kim's Kool sites followed by Go to today's kool site.
Looks like we are experiencing the Kim Effect, but our server is
holding together. :-)
Curt.
--
Curtis Olson HumanFIRST Program
Hi Matevz,
I was able to run rsync fine last night after my first reply to your
problem so I believe the rsync server should be working just fine.
Curt.
Matevz Jekovec writes:
Curtis L. Olson wrote:
Matevz Jekovec writes:
Ok, I run fgfs with the following arguments:
--fg-root=/home
Matevz Jekovec writes:
Ok, I run fgfs with the following arguments:
--fg-root=/home/matevz/fgfs/data
--atlas=socket,out,1,localhost,5500,udp
--fg-scenery=/home/matevz/fgfs/data/Scenery
--airport=LJLJ
and I run
nice terrasync -p 5500 -d /home/matevz/fgfs/data/Scenery
And I found myself
Melchior FRANZ writes:
BTW: reverting the last patch and going back to revision 1.2 fixes
the bug. But it does still not explain the client zombie.
Strange, someone suggested this as a fix. Note that previously,
read() and readline() were not consistant. the patch made them
consistant. The
Jonathan Richards writes:
On Tuesday 09 Dec 2003 9:37 pm, Norman Vine wrote:
http://perthon.sourceforge.net/
:-)
Interesting - I don't often see two (purportedly) equivalent pieces of code
together like that. I put both examples into files: the python is 668 bytes,
whereas the perl
Manuel Bessler writes:
OK, No problem. Maybe we should really consider a mailinglist for that as Al
has mentioned. Even if it'll be very low traffic.
The question would be whether this would/could be hosted officially
along the other fgfs list, or if we should set up something independet
of
David Luff writes:
Now, that I've edited a few taxiways, I could do with some advice on
airport lighting before sending them off to Robin Peel. Documentation on
taxiway lighting seems quite (very) hard to come by, so could some airport
users give me some advice for various classes of
David Megginson writes:
Possibly, but from what I've heard, the main reason for centreline lighting
on runways is to support Cat II and III ILS approaches (down to a 50 ft
ceiling); probably, the same applies to taxiway lighting, since you'll have
ground ops in *extremely* low visibility.
Andy Ross writes:
Jim Wilson wrote:
Ummm...why does this matter?
Why wouldn't it? :)
It would be nice to be able to at least be able overzoom and simulate
a telephoto lens (as before.)
Regards,
Curt.
--
Curtis Olson HumanFIRST Program FlightGear Project
Twin Cities
Andy Ross writes:
This is mind bogglingly easy to fix. But what is the desired
behavior? What I want is a limit that will tell me when I've zoomed
to as far as a human pilot would actually be able to see from the
cockpit.
What do you guys want? If you want to overzoom only from the
I just commited some fixes to the NMEA output to make it more usable.
This allows FlightGear to to pretend it is a gps and send fake gps
sentences out the serial port. You can then feed the other end of the
serial cable into something running some real moving map/gps software
and that software
Erik Hofman writes:
Jon Stockill wrote:
I've just been having a look at some of the new airports I've generated,
and I've noticed an error with the new ufo model - the great big red
anti-collision light from the front is missing ;-)
Heh, I noticed that too recently.
I was mostly busy
Simon Fowler writes:
Actually, ext3 is a better choice than XFS if you really care about
your data - it does full data journalling (at a performance cost),
unlike XFS which only journals metadata. Since it halves your write
performance people generally don't use it, but it's there in ext3 .
.
Martin Spott writes:
Curtis L. Olson [EMAIL PROTECTED] wrote:
ftp.flightgear.org is still rebooting ... /dev/hdh1 (120Gb) has gone
204 days without being checked, check forced ... might be another hour
or two ... :-)
I usually put everything over 10 GByte on XFS per 'default' - as well
Paul Surgeon writes:
Can't you just force a check every now and then from a cron job?
Anyway it's a small problem - a few hours of down time every year won't hurt
anyone.
You need to unmount the drive before fsck'ing it, which you can't do
unless all services / processes using files on that
David Megginson writes:
Does anyone know if it's possible for a Garmin GPS to take its position
information from external NMEA input, rather than just broadcasting the
position as NMEA output? I wanted to experiment with using my (brand-new)
Garmin 196 slaved to FlightGear, but I have not
John Wojnaroski writes:
Has anyone been successful in running some of the dual headed video
cards with FG?
I've never had a chance to play with a multi-headed opengl card.
However, I've always been a little dubious about what kind of results
they would yield.
If you want to render two
Andy Ross writes:
The automatic filesystem check is an issue of filesystem policy, and
says nothing about the implementation thereof. Neither, I should add,
does the appelation enterprise. :)
If I had to pick, I'd go for reiserfs because of the nifty tail
folding. But saying that XFS is
Jim Wilson writes:
The addition of this code on 10/23 to fg_init.cxx is what started the problem
with the aircraft crashing on teleports:
cout fgInitPosition() endl;
double gs = fgGetDouble(/sim/presets/glideslope-deg)
* SG_DEGREES_TO_RADIANS ;
Is there a way to preset certain property values when opening up a
dialog box? I see that we can force arbitrary property values when
clicking ok, but it would be nice to force some default values when a
dialog box is opened.
Thanks,
Curt.
--
Curtis Olson HumanFIRST Program
901 - 1000 of 2502 matches
Mail list logo
