Curtis L. Olson
> Norman Vine writes:
> > BUT does the Terrain Graph contain the tile you are
> > trying to determine the AGL from ??
> >
> > This is a prerequisite and AFAICT currently this is not gauranteed to
> > be the case until AFTER the 'load func
David Megginson writes:
>
> Norman Vine writes:
>
> > BUT does the Terrain Graph contain the tile you are
> > trying to determine the AGL from ??
>
> It should, because the OBJECT_STATIC directive occurs only in *.stg
> files, which are parsed when the tile con
Jim Wilson writes:
>
> David Megginson <[EMAIL PROTECTED]> said:
>
> > Norman Vine writes:
> >
> > > BUT does the Terrain Graph contain the tile you are
> > > trying to determine the AGL from ??
> >
> > It should, because the OBJECT_S
Bernie Bright writes:
> On Mon, 23 Sep 2002 18:51:25 -0700
> Jonathan Polley <[EMAIL PROTECTED]> wrote:
>
> > MSVC does not have fmin() defined, so complains in vacuum.cxx.
> >
>
> gcc 2.95.3 complains too. fmin() is only defined if _ISOC99_SOURCE is
defined before including .
I wonder if we ar
Martin Spott writes:
>
> did you recognize that some markers in the HUD display disappear when
> 3D-clouds come in sight ? Shortly after takeoff, when looking at the
clouds,
> I see a HUD like this:
There are LOTS of issues to be ironed out with the 3DClouds yet.
The 'OpenGL Transparency Issue' i
CAN WE RESOLVE THIS ISSUE it is a major PITA !!
- Original Message -
From: "Norman Vine" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 11, 2002 5:27 PM
Subject: [Flightgear-devel] CVS busted
> Someone else mentioned this but ...
>
September 2002 10:34 am
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Flightgear-devel] MSVC 6.0 Problem with
> > systems/vacuum/vacuum.cxx
> >
> >
> > On Tue, 24 Sep 2002 03:46:54 -0400
> > "Norman Vine" <[EMAIL PROTECTED]> wrote
Martin Spott
> > So to reiterate what Curt
> > "This isn't quite ready for general consumption"
> > but some of us are working on it
>
> Sorry, I didn't mean to hurt anyone.
No problem, just wanted to make sure everyone realizes this
is still in development :-)
___
A source for non-US 30 meter DEM's
I believe that for those areas already processed and on line
these are still free.
We would have to build a new DEM reader to handle these
but that should not be too dificult in that they are in a
'well known' format
Norman
- Original Message -
From:
ned for 2004.
Agreed - but at least it looks as if it will still be available eventually
Norman
>
> Mally
>
> - Original Message -
> From: "Norman Vine" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, September 24, 2002 12:19 P
Curtis L. Olson wwrites:
> David Megginson writes:
> > Curtis L. Olson writes:
> >
> > > The preferences.xml file specifies the c172 as the default. It
> > > appears that even if you request a different aircraft as the default,
> > > the c172 config files get loaded first anyway, then the alt
Roman Grigoriev writes:
>
> I downloaded ASTER DEM and play with it
> Nice resolution (30m) but there are so many holes to use it
> So fightgear/terragear gurus maybe you tell me is there in dem library
some
> tools to approximate aster dem data with gtopo30 data to eliminate holes?
It is current
Jim Brennan jjb writes:
> Can anyone provide this for me?
http://www.rockfish.net/~nhv/fgfs/mingw/fgfs_092602.tgz
Note this does not have LaRCSim or UIUC support as there
is a namespace clash with the beta MingW gcc compiler I
am using.
Norman
__
Michael Selig writes:
> At 9/26/02, Norman Vine wrote:
> >Jim Brennan jjb writes:
> >
> > > Can anyone provide this for me?
> >
> >http://www.rockfish.net/~nhv/fgfs/mingw/fgfs_092602.tgz
> >
> >Note this does not have LaRCSim or UIUC support as t
FYI
http://openlight.com/fdui/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Curtis L. Olson writes:
>>
> Yes, if you use an int and track time in increments of 1 / 1,000,000
> then you get about 30 minutes before you hit an anomaly. This bug
> caused problem in the past such as radio station searches to only
> happen every other 30 minute period, or panel text to stop u
Curtis L. Olson
> Norman Vine writes:
> > Yep there is a problem if you try to run a FGFS session on a
> > Windows box much over 49 days :-)
>
> I wouldn't know anything about that, and far be it from me to
> blatantly bash windows, but if you manage to have you
Curtis L. Olson
>
> I actually have a rcs/sccs book sitting on my shelf (good thing I
> proofread my messages ... I originally wrote sitting on myself which
> is close, but doesn't quite convey the same thing.) I bought it
> because it advertised a cvs section, but the cvs info turned out to be
Curtis L. Olson writes:
> I am working on interfacing an external flight model to FlightGear via
> the network. This particular code reports an altitude of zero/0.0f
> when the wheels are resting at sea level.
>
> The c172 3d model is drawn so that it's center of gravity is at the
> reported al
Sydney Weidman writes:
>
> I was just trying to compile the latest release of FG, but I got a bunch
> of errors. I notice the errors involve gcc 3.2 stdc++ headers, so maybe
> I have used an unsupported version of gcc.
>
> Some compiler error messages follow.
>
> Thanks for this entertaining
David Megginson writes:
> Norman Vine writes:
>
> > I am still not convinced that your tile is actually loaded though
> > and don't really know the 'best' way to check for that given the
> > 'lazy' loader.
>
> I can think of two options
David Megginson writes:
> I would like to make it possible to specify the elevation of static
> and shared objects AGL as well as ASL, but for that, I need to know
> the elevation ASL at a specific location (not the current view
> position). I have taken a look at the fgCurrentElev() functions i
David Megginson
> Norman Vine writes:
>
> > ie STATIC objects should be created with offline tools
> >
> > This is probably easiest to do by just adding a variation of the
> > magic-carpet mode to teleport to the positions listed in a file
> &g
FYI
I have finally managed to get the current source, to include the
LaRCsim/UIUC FDM to build with the MingW32 gcc 3.2
This is a self contained native WIN32 executable of the current
CVS files and will need the CVS base package to run
I haven't done much testing but it seems OK and
it did loa
Jim Wilson writes:
>
> Norman Vine <[EMAIL PROTECTED]> said:
>
> > If it isn't then you just need to load it before making your query to
the
> > elevation routine and then it should just work using a similar method to
> > what Jim uses for Tower placement
Andy Ross
> Norman Vine wrote:
> > FWIW - I really don't understand why the FDM folks haven't been using
> > this as I wrote it several years ago so that one could get an
> > elevation per wheel
>
> Landing gear struts compress, so there isn't a si
David Megginson writes:
>
> Norm, it depends a lot on documentation. There is far more code in
> SimGear and FlightGear than most people know about or understand.
> While I don't always keep it up to date, my 3-D model code and
> property code gets used mainly because I provided documentation to
David Megginson writes:
>
> I'm hitting a wall with my limited knowledge of calculus.
David
You REALLY NEED to read this book !!
- Original Message -----
From: "Norman Vine" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 30, 2002 7
Andy Ross writes:
>
> For reference, YASim does all of its internal mechanics in a
> geocentric cartesian coordinate system. It never usees anglular
> measures except at the interface level. In these coordinates, the
> aircraft state is pleasingly simple:
>
> position: 3 doubles
> orientatio
David Megginson writes:
> Norman Vine writes:
>
> > What happened to all of the documentation that I provided for MY
> > MATRIX routines that the 3-D Model code uses
>
> A while ago I deleted some dead, commented-out code but have tried to
> avoid usage comments
David Megginson writes:
> Norman Vine writes:
>
> > What happened to all of the documentation that I provided for MY
> > MATRIX routines that the 3-D Model code uses
> >
> fgfs-matrix-howto.html
>
> or something similar. Inline comments have some value wh
Jon S Berndt writes:
>
> Does anyone have any experience with moving from Doc++ to
> Doxygen? I'm thinking of making the move. Doxygen seems to
> be what I had hoped Doc++ would become, but seems to have
> stalled. It looks like many of the identifiers are the
Jon
Doxygen started life as Doc++ s
FYI
http://www.ngs.noaa.gov/AERO/ASPphoto/aspphoto.html
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Jon Berndt writes:
> > Jon S Berndt writes:
> > >
> > > Does anyone have any experience with moving from Doc++ to
> > > Doxygen? I'm thinking of making the move. Doxygen seems to
> > > be what I had hoped Doc++ would become, but seems to have
> > > stalled. It looks like many of the identifiers a
Erik Hofman writes:
> David Megginson wrote:
> > Erik Hofman writes:
> >
> > > Can someone explain me how to erase a member from an STL vector?
> > > I've tried several things, but it looks like it isn't removed anyhow.
> >
> > You need to use erase(), passing in an iterator (yes, I know, I hate
Moved from flightgear-users
David Megginson writes
> Mark Fisher writes:
>
> > Again, I'm looking for the location of the dictionary of permissible
> > properties that can be set using the .XML joystick files, and their
> > permissible value ranges.
>
> Take a look at the property browser
David Megginson
> Norman Vine writes:
>
> > But there are many "Fixed Lists" of properties for example
> >
> > PitotSystem::init ()
> > {
> > _serviceable_node = fgGetNode("/systems/pitot[0]/serviceable",
true);
> >
David Megginson writes:
>
> Norman Vine writes:
>
> > > I think that's a great idea, as long as we recognize that it will be
> > > perpetually a work in progress.
> >
> > In what way is this any different then the 'C' code ??
>
> N
Alex Perry writes:
> > Norman Vine writes:
> > > http://www.ngs.noaa.gov/AERO/ASPphoto/aspphoto.html
>
> Of course, for the non-free images which are dirt cheap on a per airport
> basis (given the scripting above), I note the absence of any licence
> comments on
ace project writes:
> >
> vector_of_elements.erase(&vector_of_elements[index]);
> >
> > I think your are making the too rapid assumption that
> > an iterator is a pointer to an element.
> >
> Thats the one I ment Fred (my mistake). It works for
> me (while I don't know whether is *really* corr
> Curtis L. Olson writes:
>
> > What I'm looking for is somethingn to the effect that a VASI light bar
> > is a row of "n" lights spaced "x" meters apart. VASI light bars are
> > spaced "y" meters apart along the length of the runway.
> >
> > And if I'm really lucky I'd get the difference
Curtis L. Olson writes
>
> Norman Vine writes:
> >
> > > Curtis L. Olson writes:
> > >
> > > > What I'm looking for is somethingn to the effect that a VASI light
bar
> > > > is a row of "n" lights spaced "x" meters a
Curtis L. Olson writes:
> Norman Vine writes:
> >
> > > Curtis L. Olson writes:
> > >
> > > > What I'm looking for is somethingn to the effect that a VASI light
bar
> > > > is a row of "n" lights spaced "x" meters apar
Christian Mayer writes:
> "Curtis L. Olson" wrote:
> >
> > Here's a question I'll throw out to the list on my way to bed.
> >
> > I'm working on VASI/PAPI type lights tonight and am running into a
> > problem. I'm using environment mapping with the normal aligned along
> > the desired approach
David Megginson writes:
>
> That's a good point. The other option would be to cut down the Hz for
> the AIs -- how low could we make it before the autopilot lost control
> -- 10Hz? 2Hz?
you can easily experiment for yourself by playing with the
"/sim/model-hz" value
good luck !
Norman
___
David Megginson
> David Luff writes:
>
> > I'm sure someone on this list has mentioned that they're developing an
> > interactive scenery editor, but I can't find a link to it either on the
> > Flightgear site or Google. Could someone post a link if they know it
> > please. I'm basically lo
Curtis L. Olson writes:
> David Megginson writes:
> > David Luff writes:
> >
> > > I'm sure someone on this list has mentioned that they're developing
an
> > > interactive scenery editor, but I can't find a link to it either on
the
> > > Flightgear site or Google. Could someone post a link if
Curtis L. Olson writes:
> 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 *
Alex Perry writes:
> > David writes:
> > I wonder if the casual users appreciate all the work we're doing to
> > make the instruments less reliable.
>
> Don't you remember the massive amount of whingeing (a couple of years ago)
> when I stuck all the compass turning errors onto the DG instrument
Andy Ross
> Curtis L. Olson wrote:
> > Just a couple thoughts to consider. We are looking at 16-20,000
> > airports so we couldn't stuff them all in a single directory. Even
> > splitting them into subdirectories by first letter probably isn't
> > enough.
>
> There are 17073 airports in the cu
Andy Ross writes:
> Norman wrote:
> > [ ... indexing scheme involving spacial partitions and trees ... ]
> >
> > With such a scheme we should be able to access any airport and
> > determine which airports are within some sane distance in much
> > less then a few tenths of a second < order of mani
David Megginson
>
> Norman Vine writes:
>
> > > I think "preferences.xml" and the aircraft-set.xml files pretty much
> > > cover any functionality that was intended to handle.
> >
> > PLEASE DO NOT REMOVE the .fgfsrc option until
> &g
David Megginson writes:
>
> Norman Vine wrote:
>
> > To sum up I think that the work that has been done to make the
> > 'instruments' act like a C172 is fantastic but it SHOULD be an option
> > and not 'the way'
>
> It should be not just an
David Megginson
> Norman Vine writes:
>
> > I will still argue that the method used was and still is poor
> >
> > There are those who want 'steam' and those who don't
>
> Sure, and we make both available through the property tree. If you
&
Cameron Moore
> * [EMAIL PROTECTED] (Norman Vine) [2002.10.13 00:02]:
> >
> > but FWIW I just cheat
> > http://www.crazy-compilers.com/bridgekeeper/
>
> Interesting stuff. I can't help but point out that bridgekeeper is
> written in perl. ;-)
But of
Curtis L. Olson
> Geoff Reidy writes:
> > The major problem I have with fgfs is that I seem to hit a race
> > condition where all graphics and sound stop for extended periods of time
> > (up to about 30 secs),>
> This most likely relates to freeing tile memory (i.e. moving old tiles
> out of the
Norman Vine
>
> CVS version of Cygwin
AACK
CVS version of FGFS
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Curtis L. Olson writes:
> Norman Vine writes:
> > The same thing happens for me with both Cygwin gcc 2.95.2
> > and MingW gcc 3.2 both using Doug Lea's malloc routines which
> > I believe is what most Linux distributions use
>
> It might be worth verifying that
Curtis L. Olson
> Norman Vine writes:
> >
> > FWIW - I ended up assuming that my poor little 256 meg machine
> > just wasn't big enough to run FGFS anymore under Windows as it
> > appears to be memory related disk thrashing that is killing me.
>
> Anoth
Curtis L. Olson writes:
> I dumped out the ground elevation as I went over the anomoly and
> here's what I get:
> elev = 164.032
> elev = 166.037
Norman Vine wrote:
> Curtis L. Olson writes:
>
> > Could the hitlist code be overly aggressive on what it's caching
> > internally?
>
> Maybe - should be easy enough to back out almost all of the
> modifications as I do not believe that the Interface ever chan
Jim Wilson writes:
> David Megginson <[EMAIL PROTECTED]> said:
>
> > Curtis L. Olson writes:
> >
> > > Your Wright flyer model is really starting to look sharp! Good
> > > work. :-)
> >
> > It looks great -- this is the first time I've tried it. With the
> > mouse, at least, it's also quite e
FYI
http://www.boeing.com/news/releases/2002/q4/nr_021018m.html
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Andy Ross writes:
> John Check wrote:>
> > main.cxx:153:
> >void (*glPointParameterfvEXT)(unsigned int, const GLfloat*)
> > /usr/X11R6/include/GL/gl.h:2520:
> >glPointParameterfvEXT(unsigned int, const GLfloat*)'
>
> OK, this one looks kinda wrong. Our code is defining its own copy
Alex Perry
> > Alex Perry writes:
> > > I am not aware of a GPS unit that is able to report heading rather
than
> > > track, but as far as I know, only cost is the driving factor there.
> > http://www.intnlind.com/trimble/ms860.html
> I should have said "aviation approved". Any three-antenna DGP
Alex Perry writes:
> > > Any three-antenna DGPS install can,
> > > among other things, replace all the INS platform (ignoring
availability).
>
> Norman responded:
> > AFAIK You don't need DGPS for heading
>
> I don't see how you'll manage heading reliably without going differential.
> The two link
David Megginson
> Norman Vine writes:
>
> > IMHO we should take advantage of our existing bucketing by fans
> > and put the LOD nodes at the 'leaf's branch' level instead of the
individual
> > triangle level. Just doing this would save us LOTS of node
Curtis L. Olson writes:
> Norman Vine writes:
> > > How big is the hit if you simply delete a higher-level node and let
> > > plib delete all of the branches and leaves underneath automatically?
> >
> > My guess is that we would gain more by having the random
Curtis L. Olson writes:
> David Megginson writes:
> > What I meant is that you use your scheduler a little higher up the
> > scene tree. The dynamic objects, for example, are under separate
> > branches for each scenery triangle; just deleting the top-level
> > triangle branch should be good enou
Andy Ross writes:
> David Megginson wrote:
> > How big is the hit if you simply delete a higher-level node and let
> > plib delete all of the branches and leaves underneath automatically?
>
> Probably equivalent. The overhead is usually in all the per-chunk
> bookeeping, not the function calls.
David Megginson writes:
> I little while ago, I made a posting asking how a pilot in the
> Canadian far north (where magnetic compass readings are not useful)
> could reset the heading indicator in flight using a single GPS
> receiver.
>
> The answer is actually fairly simple, if you don't mind a
Michael Basler writes:
>
> > I'll also recommend that all primary developers currently using G++
> > 2.95 on Posix systems switch to G++ 3.2.
>
> While I am not a primary developer I would be interested if it is possible
> to build under Cygwin's GCC 3.2 already?
YES - but be prepared for some
David Megginson writes:
> Curtis L. Olson writes:
>
> > However there is still an issue to worry about. The random ground
> > cover code can create thousands of objects which means a branch node
> > in our scene graph with thousands of kids. plib is not exactly
> > efficient at deleting kid
Curtis L. Olson writes:
> David Megginson writes:
> > Norman Vine writes:
> >
> > > Also even though we probably would be drawing more objects
> > > I wouldn't expect much of a hit in that there would be lot fewer
> > > culling operations
>
Tony Peden writes:
>
> Hmm, curious. How can you get anything but ground track from a single
> receiver with a single antenna?
You can't, but ...
your ground track is a 'heading' if ...
you keep a steady course.
This is not as hard as it sounds with a GPS because
most units allow you to progra
FYI
http://www.aechelon.com/media/images_psi.html
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
FYI
A lot of good stuff here much of it is directly applicable
http://ocw.mit.edu/13/13.49/f00/index.html
The book though aimed at the marine enviroment should be a good read
for any control-simulation engineer
Norman
___
Flightgear-devel mailing l
David Megginson writes:
> Curtis L. Olson writes:
>
> > I think Norman was talking about some sort of automated magic carpet
> > mode.
Exactly
> That would be slow,
use minimal visibility and turn off any calls that actually render anything,
ssgCullAndDraw, pre(post)RenderSky ect, and it sho
David Megginson
>
> I don't think you really need a proper autopilot for using true
> values, just something that works with the magic FDM and moves the
> plane in a certain direction at a certain speed -- more of an
> animation manager than an autopilot.
http://gps.faa.gov/Programs/WAAS/waas.htm
David Megginson writes:
>
> Instead, we should set the appropriate switches to 'on' in
> preferences.xml or c172-*-set.xml so that the user can override. For
> the starter, a default to 'on' is clearly not what we want.
NIT
*-*-set.xml so that the user can override.
The Sim is more the
David Megginson writes:
>
> Please remember that FlightGear is not just a
> visualizer for batch-mode aero runs -- people use it to fly
> interactively.
NIT: Please remember what it says on our Home Page
"""The FlightGear project is working to create a sophisticated flight
simulator framework fo
David Megginson
>
> Norman Vine writes:
>
> > > I don't think you really need a proper autopilot for using true
> > > values, just something that works with the magic FDM and moves the
> > > plane in a certain direction at a certain speed -- mo
Simon Fowler writes:
>
> What about simply putting all the airport files in the scenery, and
> having a script that searched through the scenery directories for
> all the *-apt.xml files and built/updated a set of indexes from
> them? That keeps the files in the right place, and gives the indices
>
David Megginson writes:
> Norman Vine writes:
>
> > 2) is a little more complicated but we allready have a good start
> > if we leverage the Scenery directory structure
>
> Agreed.
>
> > I suggested using a quadtree for each 10x10 degree block
Andy Ross
>
> Right. But this indexing of "nearby" objects can be done in memory
> (since the set of nearby objects is already available via the tile
> set). There's not need for anything fancy on disk.
FGFS should be able to answer simple flightplan questions
like "I am leaving from KSFO flying
Cameron Moore"
> >
> > Ooh! So you run a 64-bit C compiler!
>
> No, but I know Perl! When I get a chance, I try to port anything Norman
> does in python to perl just because I know he hates it. hehe ;-p
This should help
http://starship.python.net/crew/da/jak/cookbook.html
and you can use th
David Megginson
> Tommygio writes:
>
> > 1) The swtch "--cloud-disable" disables the default cloud layer,
> > but not the "puffy" effect at the layer altitude.
>
> OK, I've just fixed that -- the changes will appear in CVS shortly.
>
> > 2) In the chase view with the default airplane, the cock
Jim Wilson writes:
> Hmmm... I did a google on "spirit level wright flyer" and nothing came up.
> Any idea what it looks like?
Probably like one < oops two > of these
one aligned with the wing and one aligned with the body
http://www.stanleylondon.com/inclinometer.htm
Norman
___
David Megginson writes:
>
> Are there simple technical terms to distinguish the digits on the left
> side of the decimal point from those on the right?
whole part . decimal part
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear
Jon Berndt
> I've got a few minutes to spare this evening, so I'm going to try again to
> build the latest development flightgear.
>
> Questions:
>
> 1) I plan on using the latest "bleeding edge" flightgear sources from
> development CVS. Which base package do I download?
>
> 2) Does the base pack
Andy Ross writes:
> OK, I *finally* got a chance this weekend to sit down and crank on
> FlightGear code. It's been a while. Attached are three patches for
> review. Complete files for Curt are available at:
> http://www.plausible.org/fgfs-andy-2002Oct26.tar.gz.
>
> The first is just a port of
Andy Ross writes:
> Norman Vine wrote:
> > Your scrollable HUD is GREAT but can you make this a 'preferences'
> > controled option so that we can keep the older HUD as there are
many
> > reasons for having a 'fixed' fullscreen HUD too.
> Ther
David Megginson writes:
>
> Curtis L. Olson writes:
>
> > We artifically raise the lights a bit to attempt to avoid zbuffer
> > fighting. The formula is based on the altitude above ground and the
> > distance away ... however, it's rough and imperfect ...
>
> I'm still working on understandin
'Johnny' wrote:
> Now, what broke?
The 2D HUD
>You still haven't answered what it is you want,
The functionality of the 2D HUD
>Seriously, name your requirement
Seriously, The functionality of the existing 2D HUD
> and we can try to meet it.
Thank you very much for the offer but sin
Andy Ross writes:
> Norman Vine wrote:
> > Andy Ross wrote:
> > > You still haven't answered what it is you want,
> > The functionality of the 2D HUD
> > > Seriously, name your requirement
> > Seriously, The functionality of the existing 2D HUD
David Megginson writes:
> Andy Ross writes:
>
> > Norman, this isn't constructive. Here are some things I'm quite
> > certain you don't want:
> >
> > + A velocity vector that doesn't point where the aircraft is going
see the discussion about the horizon below as to part of the problem
>
Jon Berndt writes:
>
> The simgear CVS retrieval still hangs.
It is a known problem that using compression with the
Cygwin cvs executable will cause an apparent hang
FYI
What actually happens is a failure to return after the operation
has finished, this is indistinguishable from a hang from the
David Megginson writes:
>
> Here is the approach they were flying (I think):
>
> https://www.americanflyers.net/ap/default.asp?t=download&f=L\011L$100.PDF
Here is a good mapping engine for the site
http://www.dnr.state.mn.us/maps/landview_dhtml.html?mapsize=large&zoomsize=2&mapext=526604.225305
Michael Selig writes:
>
> > > > > I am trying to compile and run the latest version of fgfs, but I have
> > > > > hit a problem. When I run it I promptly get the error message
> > > > > "Segmentation Fault"
> > > > > There are no other messages.
> > > >
> > > (gdb) run
> > > Starting program:
> >
Andy Ross writes:
>
> Not quite. The big change was making it resolution, FOV, and aspect
> ratio independent. I figured that if it had to be changed anyway, I
> might as well invert it to mean what it says. There is no way to keep
> the old scaling scheme and be view-independent at the same tim
301 - 400 of 1464 matches
Mail list logo