David Megginson writes:
>
>Olivier Grisel writes:
>
> > So if we develop such user friendly tools, it might be a
> > good idea to choose only one gui style so as they get all
> > the same style.
>
>You work sounds great. I see no harm in having both Java and Python
>GUIs -- I'm no Python fan myse
Tony Peden writes:
>
>Norman Vine wrote:
>
>> David Megginson writes:
>>
>>>Olivier Grisel writes:
>>>
>>>
>>>>So if we develop such user friendly tools, it might be a
>>>>good idea to choose only one gui style so as they g
Tony Peden writes:
>
>>>
>
>Scripting languages are good stuff ... but they are still languages.
Agreed :-)
but this was in reference to 'ease of use' for 'users' not 'developers'
hmmm
maybe FlightGear 'users' all know how to run compilers :-))
Cheers
Norman
__
FWIW
I haven't been able to get an update from the fgfsbase cvs all day
I can connect OK but then cvs gets stuck responding with
"cvs server: [ $time ] waiting for cvsroot's lock in
home/cvsroot/FlightGear/FlightGear"
every 30 seconds
???
Norman
fgfs --help
exits with an error message about 'options.xml' missing
Shouldn't this be in fgfsbase ??
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Some other interesting DEM related stuff at this site also
http://members.fortunecity.com/eco4/giseco/id8.html
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Andy Ross writes:
>
>Norman Vine wrote:
>> Check your editor's help file for 'multi-file grep' or
>'multi-file search'
>>
>> IMHO this is an indispensible editor feature for developing 'large'
>> projects and most 'good&
David Megginson writes:
>
>Andy Ross writes:
>
> > Blam. Culture crash. Most of us unix geeks would contend until the
> > day we die that doing a recursive search via a GUI
>interface is slower
> > and more error prone than running find and grep.
>
>Nah. I like running find, grep, and etags fr
ima sudonim writes:
>
>Norman, I'm glad that you brought that up (it was my next question):
>What code editors do people recommend using? I can sort-of use vi, the
>one time I started emacs, I couldn't exit the darn thing.
A quick 'google' turned up several 'poweful' editors that I am familar
Andy Ross writes:
>
>+ This one really annoys me: the AC3D file format apparently doesn't
> allow you to specify normals explicitly, it wants to calculate them
> itself. This works fine for the vertices inside the texture, but
> texture boundaries show up as sharp edges because the polygons in
Andy Ross writes:
>
>Jim Wilson wrote:
>> Andy Ross wrote:
>> > What might be easier, though, is allowing for a optional 6-element
>> > vertex line that included the normal.
>>
>> We should be able to load into ac3d. But if we embedded commands
>> into the name tags we'd be ok.
>
>Ah, I see what
Andy Ross writes:
>
>Christian Mayer wrote:
>> Andy Ross wrote:
>> > Problem is, I don't know anything about the glut font format, and a
>> > cursory look around the web didn't turn up any pointers. Does
>> > anyone know this stuff well enough to write up a quick format
>> > document?
>>
>> You d
Andy Ross writes:
>
>I got bitten by some static data corruption problems
>
> sprintf(buffer, "%05.2f", value);
>
>In my copy, I fixed this with snprintf, but something nags at me that
>this isn't portable to some platform we care about.
#include
should take care of snprintf portability pro
Andy Ross writes:
>
>I got bitten by some static data corruption problems while working on
>the panel stuff this afternoon (which I have almost working, by the
>way -- expect a big code drop tomorrow morning). I tracked it down to
>a buffer overflow in auto_gui.cxx. In the string formatting code
Andy Ross writes:
>
>Norman Vine wrote:
>> Check Marks's document about Textured Fonts for further information.
>> Of particular interest is Mark's "gentexfont" program that can create
>> a TXF format font from an X-windows font.
>
>This is how
ace project writes:
>
>
>> The first important decision now is, do we
>> > multi-threading or multiplexing-IO ? For multiplexing,
>> > PLIB can be used. For multi-threading, we got a problem.
>> > Another issue is how to get the code to compile on
>> > other platforms, because threading and socke
Andy Ross writes:Glut font format
>
>
>Norman Vine wrote:
>> Here's Mark's example of the command used to generate the
>sorority.txf
>> file: Just change the Font name and the 'glist' to be what you want
>>
>> gentexfont \
>&g
Andy Ross writes:
>
>Norman Vine wrote:
>> I think that you will find that inorder to get 'high quality' fonts
>> one needs to use a vector based font directly. The only problem in
>> doing this is that the polygon count goes up considerably.
>
>Have you t
[EMAIL PROTECTED] wwrites:
>
>I have found it generally useful to have them provided, and
>have wished the plib would do the same (for .deps directories,
>in particular).
FYI
the FlightGear 'configure' is designed to be able to be run in
a directory other then then the CVS source tree.
This has
Jim Wilson writes:
>
>Andy Ross <[EMAIL PROTECTED]> said:
>
>> Jim Wilson wrote:
>> > On further investigation, it appears that this is almost certainly due
to
>> > normal variation in fdm position and orientation output.
>>
>> This theory doesn't work though. Think about it: in cockpit mode, the
Erik Hofman writes:
>
>There is a small proble though, is there any way to pass an
>argument to
>a PLIB menuBar Callback function?
NO
use class data members, global variables or functions to get
the 'arguments' within the callback()
Norman
___
Norman Vine writes:
>
>Erik Hofman writes:
>>
>>There is a small proble though, is there any way to pass an
>>argument to
>>a PLIB menuBar Callback function?
>
>NO
>
>use class data members, global variables or functions to get
>the 'argum
Erik Hofman writes:
>Isn't there any trick with the puObject member either (I just need to
>know which menu entry is causing the callback)?
why not just use use the puObject pointer
/* print the 'menu text' of calling menu entry on stdout */
void tattle_tale_cb( puObject *me)
{
printf("
Erik Hofman writes:
>
>David Megginson wrote:
>>
>> Erik -- what do your bindings look like?
>
>You mean the code to bind a JavaScript function to a C function:
>
>static JSBool
>_fgs_set(JSContext *cx, JSObject *obj, uintN argc, jsval
>*argv, jsval *rval)
>{
>const char *node, *str;
>
>
James Turner writes:
> A couple of comments on the
scripting issue:
> JS is very effective and>
manageable, orders of magnitude moreso than Perl.
This
is good to hear.
> Python is equally> good as the code size grows, but the syntax puts
people off
a simple matter of taste, for
David Megginson writes:
>
> (I'd love a programming environment on my Palm V, for example)
Hmm.. I sense a potential Python convert lurking in these words :-)
http://pippy.sf.net
Enjoy
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http:
David Megginson writes:
> -- plib has a new (mostly undocumented)
>particle system designed for just that sort of thing.
Have you seen
http://toobular.sf.net
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mai
David Megginson writes:
>
>Cameron Moore writes:
>
> > Here's another dumb suggestion: It would be pretty cool is someone
> > would turn off the sun at night. This is a known issue[1],
>but it's a
> > pretty glaring (no pun intended) bug.
>
>Yes, I've had this discussion as well. The sun should
David Megginson writes:
>
>That's what I had thought as well, but it turned out not to be the
>case. The string constructor is expensive, and we ended up using lots
>(and lots and lots of them), running, as we were, 30-100 iterations
>per second through hundreds of properties. Switching from str
Gene Buckle writes:
>
>I get the attached error when building Metakit. I'm using the latest
>Cygwin installation.
>Any ideas?
I just < after reading your message > tested this by untaring the metakit
tarball
distributed with SimGear and then followed the instructions
i.e.
% cd builds
% .
David Megginson writes:
>
>Norman Vine writes:
>
> > as far as I am concerned creating an ASCII property path
> > is a waste of time and should not be used anywhere inside
> > the 'main loop'.
>
>Inside the main loop, it's used only for things like
Jim Wilson writes:
>
>My first concern would be about the overhead of transforming
>the terrain each frame (lots and lots of vertices).
This is already being done.
To experiment I believe all you should have todo is change the
value for 'center' in prep_ssg_node( vis, up, center );
in tilemng
Jim Wilson writes:
>
>Norman Vine <[EMAIL PROTECTED]> said:
>
>> but see
>> FGViewMgr::update (double dt)
>>
>
>Yes, all those should be moved to nodes in the view class.
>How did this look in the last profiling run?
Can't remember
FWIW - I d
David Megginson writes:
>
>Norman Vine writes:
>
> > >Yes, I've had this discussion as well. The sun should stop being a
> > >light source once it's, say, 15-30 deg below the horizon. Otherwise,
> > >it lights up the bottoms of objects at night.
&
David Megginson writes:
>
>Norman Vine writes:
>
>
>The model is not in its own graph in external view, and this problem
>far predates the new model code in any case. Here's a thread from
>December 2000, when it was already an old problem:
>
>
>http://www.men
David Megginson writes:
>
>Norman Vine writes:
>
> > Probably more with the 'model' now being in it's own 'graph' which
> > is called after other code has 'mucked' with the lighting after it was
> > setup to use the proper 'ambi
Andy Ross writes:
>
>Jim Wilson wrote:
>> I can see what you are saying...but the aircraft (in the cockpit view)
>> is actually a different scene graph.
>
>But it's under the same camera (oddly, ssg puts the global camera
>"outside" the graph, when it's logically the top-level node of the
>graph),
Andy Ross writes
> The right solution (ignoring orientation, which is
>fine as-is) is this:
>
>Move 0m in the camera
> Move +1000m
>Draw the terrain
> Move ~1m to the aircraft origin
>Draw the cockpit
Indeed ... which is why I pointed out 'where' in the code
it was easiest to do this
Andy Ross writes:
>Norman Vine wrote:
>> I guess I wrongly assumed that everyone would read this as "just add
>> the appropriate offset to move the camera to the origin" :-)
>
>Unless I'm still not understanding you,
we do seem to have a communication gap :-)
Andy Ross writes:
>
> Just adding an offset to the camera is what's already being
>done, and it runs into precision problems. The trick is to make sure
>that the camera is *never* moved to the scenery centroid before
>rendering the model.
Right ---
So why not leave the camera at 0,0,0 and add
David Megginson writes:
>
>Andy Ross writes:
>
> > Unless I'm still not understanding you, I think you misunderstand the
> > issue. Just adding an offset to the camera is what's already being
> > done, and it runs into precision problems. The trick is to
>make sure
> > that the camera is *never*
FYI
http://xplusplus.sourceforge.net/index.htm
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Jim Wilson writes:
>
>Norman Vine <[EMAIL PROTECTED]> said:
>
>> Andy Ross writes:
>> >
>> > Just adding an offset to the camera is what's already being
>> >done, and it runs into precision problems. The trick is to make sure
>> >t
Hi All
I got a considerable boost in the frame rate from the following
patch to PLib. < ~25% at default startup location >
I am trying to determine if this also true for 'most' systems
before advocating it's inclusion into PLib
If you do test this please report back with your results
and system
Victoria Welch writes:
>
> cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/SimGear-0.0 login
>
>-^^ (add .18?)
>
>But taking it as that is what I should do (not adding version) I end up
>with the following:
>
>{/usr/local/src/SimGear} $ aclocal ;
Jim Wilson writes:
>
>Anyone else noticing that both the a-4 and c172 models are
>rendering like they
>have emissive all the way up on the whole model? No shading
>at all. The other models seem fine.
the c172 model seems like it probably has a 'backface' problem
eg notice how the polygons are
Norman Vine writes:
>
>the c172 model seems like it probably has a 'backface' problem
>eg notice how the polygons are outlined in yellow
Ack please disregard my earlier 'WAG'
I just looked at the raw texture file and noticed that the background
color is the s
FYI
http://virtualcities.ida.org/virtualcities/virtualcities.html
These models are available for free
< see link to developers den >
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-
Andy Ross writes:
>
>Christian Mayer wrote:
>> I don't know if zipped packages help much for the kind of data you are
>> sending. You can only compress redundant information
>
>Amen. He speaks the truth.
>
>But note that there is lots of opportunity for compression here; it's
>just that dumb gene
David Megginson writes:
>
>I've just checked in a major revision to my new randomly-placed object
>code: i
>
>Please everyone give this a brutal workout to find any further
>problems. To enable randomly-placed objects, use
>
> fgfs --prop:/sim/rendering/dynamic-objects=true
Frame Rate report
David Megginson writes:
>
>To be fair, I've never been able to reproduce your framerate reports.
>Patches that, say, add or subtract 20 or 50% framerate for you (Norm)
>usually make a difference of less than +-5% for me. I wonder what
>difference in our systems could account for this.
I believe
David Megginson writes:
>
>David Megginson writes:
>
> > > 2. I used callbacks to prevent empty object branches from being
> > > culled. Perhaps a placeholder with a dummy bounding
>sphere would be
> > > better, since we'd still get FOV culling, but this will need more
> > > work.
> >
> > I
Curtis L. Olson writes:
>
>David Megginson writes:
>> Alex Romosan writes:
>>
>> > i was flying the a4 trying to dodge buildings when i
>crashed into one
>> > of them. the problem is i was some distance away from it
>as you can
>> > see from the picture at
>http://caliban.lbl.gov/a4_crash.p
Curtis L. Olson writes:
>
>The problem only seems to happen when the 3d model is in the view. To
>me, that would point to a problem with the model, or a problem with
>plib's handling of the model. For instance if the 3d model tickles
>some material or lighting feature that plib doesn't normally
David Megginson writes:
>
>Erik Hofman writes:
>
> > It might be usefull to rearrange the website, to let the Table of
> > Contents show up first on the page. It would be a good idea to add the
> > News and Project Overview sections to the table of contents then.
>
>I'd suggest that starting with
David Megginson writes:
>
>Norman Vine writes:
>
> > FWIW IMHO pictures do not belong on the main page at all !!!
>
>I'm not a graphics fan myself.
>
>On the other hand, when I go looking at other open-source projects'
>home pages, what I almost alwa
Norman Vine writes:
>
>Curtis L. Olson writes:
>>
>>The problem only seems to happen when the 3d model is in the view. To
>>me, that would point to a problem with the model, or a problem with
>>plib's handling of the model. For instance if the 3d model
Curtis L. Olson writes:
>
>Ok, that was definitely helpful. If you go to src/Model/model.cxx,
>line #248 and comment out the "Load panels" section of code, the C172
>becomes shaded again and the objects no longer glow at night.
Good one !
Looks like we need something like
void
FGPanel::draw()
Norman Vine wrote:
>>
>> > FWIW IMHO pictures do not belong on the main page at all !!!
>>
>Instead IMHO we should present a 'well organized' entry point
>that is viewable on one page so as to impress our visitors with our
>'professional
r component in the range [0..1] ?
YES !
Seeing these out of bound values makes me 'suspect' that there is
something in the model that is corrupting the PLib parser with this
model.
However I haven't been able to track down exactly what is going on :-(
Norman
>- Origin
Melchior FRANZ writes:
>
>Here's why my tdfx v3 doesn't show fog any more[1]: it's the
>glPolygonOffset() in the 3D-panel code. And I remembered that
>Andy had commented on this problem a while back in the already
>mentioned thread ...
< snip >
>Index: panel.cxx
>
Curtis L. Olson writes:
>Melchior FRANZ writes:
>> * Norman Vine -- Tuesday 23 July 2002 21:44:
>> > > glPopAttrib();
>> > >+ glPolygonOffset(0, 0);
>> > > glDisable(GL_POLYGON_OFFSET_FILL);
>> [...]
>> > Does this sligh
Curtis L. Olson writes:
>>
>Up until recently glPolygonOffset() was an vendor extension to the
>official spec, perhaps that's why it's not included in glPush/PopAttrib()?
Hmm... Looking at the NEW 1.4 OpenGL spec it appears as if
glPolygonOffset() has been included in the spec since v1.1 < 1992
David Megginson writes:
> Curtis L. Olson writes:
>
> > I don't know a lot about the 3d clouds, but I was under the impression
> > that you could define different cloud shapes and complexities. We are
> > just running with the cloud layout from Mark's demo.
>
> Understood. The demo is mea
John Wojnaroski writes:
>
>Curtis L. Olson writes:
>>
> > David Megginson writes:
> > > I'm wondering if we can make everything a bit simpler -- smaller
> > > textures, fewer particles, etc. We'd still get 3D clouds, but they
> > > wouldn't hit the GPUs as hard.
> >
> > I don't know a lot about t
The Bergrens writes:
> Sounds like you need the perl module called "strict" to be installed.
> Or maybe your perl installation is hosed.
> You can get perl modules from cpan.org, I think.
There was a bug in Cygwin Perl that 'can' be triggered by automake
when running on a project on a 'text' mou
Michael Basler writes:
>
> > maybe on windows all is OK and problem is related to linux?
>
> Don't worry, on windows (cygwin), SimGear does not even compile - yet,
> despite all the patches ;-) - I think Norman is working on that, though.
Things were going rather well for me on Windows then I d
Curtis L. Olson writes:
> Jim, Norman,
>
> I'm getting the following compile error:
>
> fg_init.cxx: In function `void fgInitView()':
> fg_init.cxx:667: no matching function for call to `FGViewer::get_LOCAL ()'
oops ... forgot one :-)
< I was doing a little sanity checking >
// $FG_SRC / Main
David Megginson
> Curtis L. Olson writes:
>
> > The MSVC work spaces are generated automatically whenever I run "make
> > dist". I have taken care of this.
>
> Thanks for handling that. If the files are autogenerated, we might
> want to yank them out of CVS.
Most MSVC users probably don't h
I think you are on to something !
That would explain the lightening of the clouds
with each pass. BUT this only started after I
updated my code the other day !. Also I never
had the 'text' texture
FYI
I have to leave FGFS alone so I get some real work done
for a couple of days, mapserver stuf
Boslough, Mark B writes:
> I can build the stable cvs versions
> of simgear and flightgear now, but the devel version of simgear
> does not build, failing as follows:
> SkyContext.hpp:40: extgl.h: No such file or directory
Do a cvs update
Hopefuly this should all be in place as of a couple of
Curtis L. Olson
> Norman Vine writes:
> > I think you are on to something !
> >
> > That would explain the lightening of the clouds
> > with each pass. BUT this only started after I
> > updated my code the other day !. Also I never
> > had the 'text
Curtis L. Olson writes:
>
> I don't think anyone has sent me a copy of extgl.h to add to the cvs
> repository.
It is in this tarball
http://rockfish.net/~nhv/fgfs/clouds.tgz
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.fl
Jonathan Polley
>
> I did see this code block in SkySceneLoader.cpp (I assume that it is
> global data):
>
> // Need to add a light here until we figure out how to use the sun
> position and color
> SkyLight::SkyLightType eType = SkyLight::SKY_LIGHT_DIRECTIONAL;
> SkyLight *pLight = new SkyLig
Boslough, Mark B writes:
> I did that for both SimGear and FlightGear. Now I can
> build SimGear without any problem, but FlightGear no
> longer builds! Here is the error:
>
> undefined reference to `glInitialize'
> undefined reference to `glActiveTextureARB'
>
> Any ideas?
Try the following
Boslough, Mark B writes:
> I just tried that and unfortunately I get exactly the same problem.
OK I know what the problem is
> I am going to try again from scratch.
Try changing SimGear\simgear\sky\clouds3d\Makefile
around line 99 to read like this
EXTRA_WIN32_SOURCES = extgl.c
#EXTRA_WIN
David Megginson
> Matthew Law writes:
>
> > BTW, well done on the clouds guys they're coming along nicely and will
look
> > pretty sweet when they're done :-)
>
> I agree, but I'd be happier if they'd work with 16bpp as well as 32bpp
> (32bpp is too slow at 1600x1400 on my notebook). I guess I
- Original Message -
From: "Michael Basler" <[EMAIL PROTECTED]>
To: "Norman Vine" <[EMAIL PROTECTED]>
Sent: Thursday, September 19, 2002 3:53 PM
Subject: RE: 3d Clouds code
> Norman,
>
> > Could you send me your copies of
> >
> &
Jonathan Polley writes:
> I decided to enable the 3D clouds so I could see the source of my
> recent pain ;). It seems as if the file large.sky as some endian
> issues.
Hmm... didn't someone 'hand edit' large.sky recently ?
Norman
___
Flightgea
David Megginson
> Norman Vine writes:
>
> > I doubt if any amount of fiddling would make the 3D clouds work well in
> > anything less then 32 bit color, as the eye is VERY sensitive to grey.
>
> I'm looking for work-at-all, not work-well. I don't care if
Curtis L. Olson
> Norman Vine writes:
> > Jonathan Polley writes:
> >
> > > I decided to enable the 3D clouds so I could see the source of my
> > > recent pain ;). It seems as if the file large.sky as some endian
> > > issues.
> >
> >
David Megginson
>
> Unfortunately, that's not an option -- to my knowledge, I have the
> most powerful GPU available in a notebook
the newer ATI Radeon Mobility and the GeForce4 440
are much faster but AFAIK this one smokes em all
http://www.dell.com/us/en/bsd/products/model_precn_precn_m50.htm
Curtis L. Olson writes:
> We might need to learn more about how the imposters are rendered. I
> don't think this is an issue of drawing the imposter once it is
> generated, but in generating the imposter in the first place.
The Impostors are generated with regular OpenGL calls just
like everyth
Michael Basler
> Norman Vine wrote:
>
> > Ah there was a typo in the Makefile.am
> >
> > 'corrected' one attached
> >
> > SimGear/simgear/sky/clouds3d/Makefile.am
> >
> > Please 'report' back to the list as to how this works
David Megginson writes:
> Wolfram Kuss writes:
>
> > PLIB is AFAIK able to do that with a technique called tweening. There
> > is even an example of it, where a ball is tweened to a star and vice
> > versa.
>
> I'm not sure how that would work with the loaders, though -- do we
> have to gua
David Megginson writes:
>
> Curtis L. Olson writes:
>
> > Mark Harris mentioned that the back buffer requires a "destination
> > alpha" for imposter rendering to work. Perhaps that's why things
> > aren't great with a 16bit color buffer, you probalby aren't even
> > getting an alpha channel t
Jon S Berndt writes:
>
> Just to be sure:
can you see the clouds ??
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
- Original Message -
From: "Boslough, Mark B" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 20, 2002 5:40 PM
Subject: RE: [Flightgear-devel] Still can't build devel CVS
>
> That is correct.
mark
Part of the problem is I can not connect to CVS
so I am not reall
Frederic Bouvier writes:
> http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-clouds3d-prop.png
>
> Any idea ?
Yep, This is a known problem
so
Don't do that or disable the propellor node in the model
when you are in a 3D cockpit of a plane with a propellor
norman
_
Boslough, Mark B
> I am still unable to link FlightGear, getting the same
> errors. I started again from scratch and made the modifications
> you suggested, and still get:
> /usr/local/src/cvs-devel/simgear/simgear/sky/clouds3d/SkyContext.cpp:57:
> undefined reference to `glInitialize'
>
/usr/loc
Does anyone have any experience with this ?
It looks as if it could be quit useful
http://home.in.tum.de/~atterer/jigdo/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Curtis L. Olson writes:
> Jonathan Polley writes:
> > I have a few questions brought about by some recent experiences, but
> > what they boil down to is "Are we going to reestablish the minimun
> > system requirements for FlightGear."
> >
> > First, due to deficiencies in the compiler, it is be
Alex Perry
> > > Does anyone have any experience with this ?
> > > It looks as if it could be quite useful
> > > http://home.in.tum.de/~atterer/jigdo/
> > ..yes, especially if we develop a FG linux distro to
> > go with FG, think of jigdo as "rsync for iso's".
>
> I've been looking at Knoppix,
Curtis L. Olson writes:
>
> Usually my common mistaek is to statr reversing letter piars when I
> get really tired or overly pumpde up on caffiene, and I remember
> taking about 4 tires to type that in before I got it "right".
>
> Srory about that.
Good one :-)
> >
> > this is currently $(EXT
David Megginson writes:
> I strongly recommend that anyone still using 2.95 switch to 3.2
Ack
I STRONGLY reccomend that anyone using Cygwin hold off
switching from the 2.95.x until after there has been an
'official release' for Cygwin
There are 'good reasons' this release hasn't ha
Jon Berndt writes:
>>
> is there a low-traffic cygwin-announce list that us cygwin users might
> want to subscribe to, and do you know of a link to the subscription page?
http://cygwin.com/lists.html
___
Flightgear-devel mailing list
[EMAIL
Curtis L. Olson writes:
>
> Norman Vine is the architect of the ground intersection code and it is
> sufficiently complicated that probably no one else has dug in and
> tried to understand it ...
This might help someone get started
http://seneca.me.umn.edu/pipermail/flightgea
David Megginson writes:
> Bernie Bright writes:
>
> > I was wondering if it might be useful to include a c++ program too
> > since most Windows programmers don't have perl.
>
> Or rewrite it in VB.
Here is one in Python
This will accept input in decimal or optionally in
in sexagesimal for
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 writes:
>
> I've tried the request in two places:
>
> 1. When the *.stg file is first parsed and the OBJECT_SHARED directive
>is found.
>
> 2. When the deferred model is actually loaded.
>
> Both gave no intersection.
BUT does the Terrain Graph contain the tile you are
tryi
201 - 300 of 1464 matches
Mail list logo
