Erik Hofman wrote:
I try to get it working when on the ground only by adding the
following tho the YASim configuration file:
control-input axis=/gear/gear[0]/wow control=EXTEND/
which checks for weight on the nosegear, but it seems to work
inverted. Andy?
You can play with the
Erik Hofman wrote:
Andy Ross wrote:
You can play with the src0/src1/dst0/dst1 attributes to get any
linear mapping you want.
Hmm, Im not sure I can do what I want then. What is needed is a
switch that says, hey if this property is false then ignore this
input.
Is this possible at all
David Megginson wrote:
2. Turbulence does a linear fade-out within two wingspans of the
ground.
The second item is there merely to annoy Jon into implementing
something more realistic.
Actually, that sounds pretty good to me. Doing realistic turbulence
models near the ground is
David Megginson wrote:
As long as I have you on the line, Andy, how hard would it be for you
to adapt the FGAtmosphere::Turbulence() function (in
src/FDM/JSBSim/FGAtmosphere.cpp) for YASim?
It looks like it should be fairly clean. You would take the
per-iteration turbulence vector and add it
Norman Vine wrote:
-lopengl is there in the link line
*but* it is in the wrong place
i.e Win32 linkage is quite different then Unix linkage and the order
of the libraries *is* important ie sybols must be resolved *after* they
are used.
Actually, Unix-style compilers are sensitive to link
[Chiming in because the subject is cool, and because I'm currently
stuck debugging a parser that is giving me fits and need a break.]
David Megginson wrote:
For the cockpit view, it might be interested to add optional
acceleration effects to make up for the lack of full motion -- I think
I
Jumping in here, just to prove to folks that I'm still alive. :)
James Turner wrote:
I'm pretty adamant that's the wrong way to do this, we're reduced to
polling. Being anal for a second, SGPropertyNode is an interface, and
therefore is supposed to make some guarantees about it's behavior. One
Michael Pujos wrote:
Yes but there are techniques to sustain high poly count, none of which
would be easy to integrate in flightgear. One great demo of high poly
count terrain rendering with LOD is the chunked LOD demo from Thatcher
Ulrich (http://sourceforge.net/projects/tu-testbed). This
Curtis L. Olson wrote:
For the C++ experts, I'm starting to see a lot of these sorts of
warnings? Other than trying to avoid and clean up warning litter, is
this dangerous? What's the best fix for this?
warning: `class FGGlobals' has virtual functions but non-virtual destructor
If you have
Curtis L. Olson wrote:
I've just commited some aircraft updates from Lee Elliott to the base
package cvs.
This is a neat aircraft to fly and is crying for someone to add
textures to the beautifly done 3d model.
Indeed, Lee rocks. But seriously, someone needs to come to his home,
tie him
Curtis L. Olson wrote:
One that I have enjoyed is following the Columbia river. If you
start from Portland, OR (KPDX) the airport is right next to the
river.
For those who haven't seen it, the Colombia River gorge is even better
in reality, too. And while we're on the subject of Portland, I
Matthew Johnson wrote:
Major A wrote:
does the 747-yasim segfault fgfs on everyone's computer?
Yes I get a segfault too
I can't reproduce this with the command line solver (and can't run
fgfs from work). Crashes in YASim are (well, have been) almost always
in the parser, and happen due to
[Sorry for the delay. This one was hard, and had to wait for the
weekend for an investigation.]
David Megginson wrote:
Andy: unfortunately, none of your suggestions helped (details
below). How are you modelling washout in YASim? From the violent
roll that comes with every stall, it looks
Arnt Karlsen wrote:
..some planes use distinctly different airfoils, leading edge cuffs,
slots etc, towash out. Some different-airfoil wings transform
gradually towards the tip, and not neccesarily in a linear fashion,
some of these can get really weird.
Actually, this is supported already,
David Megginson wrote:
I found it easier simply to picture different 2D sections of the
wing stalling at different times, but I can see how your explanation
might lead to a programmatic solution faster.
Right, but what is it about different secions of the wing stalling at
different times that
Major A wrote:
#0 ssgSGIHeader::getRow() at ssgLoadSGI.cxx:211
#1 ssgSGIHeader::ssgSGIHeader(...
/usr/local/FlightGear/lib/FlightGear/Aircraft/747/Models/boeing747-400-jw-08.rgb,
...)
at ssgLoadSGI.cxx:328
This is plib crashing while trying to load a texture file. My guess
is
Bernie Bright wrote:
The very first thing FG displays is its version number and compiler
info:
[...]
It would be trivial to add a timestamp.
A much better idea would be to store a time in the CVS archive.
Relying on a compilation date can bite you in very strange ways. Who
knows when the
Curtis L. Olson wrote:
However, I can only open one receiving server on my machine.
Subsequent processes fail to open the socket returning Address
already in use.
Are you sure you're using the broadcast address configured for your
ethernet device? I might be wrong on this, but I believe the
Gene Buckle wrote:
Andy, is it technically possible to fiddle with the model parameters
in real-time?
Not easily. Changing the parameters requires a re-solution, which can
take a second or two for aircraft with lots of elements like the 747.
So it would have to be done a little bit at a time
Gene Buckle wrote:
My thought is that a real-time model wrench might make it easier for
people to develop or improve aircraft models.
I imagine it would save a _lot_ of time if the edit parameter file,
run fgfs, test, re-edit cycle could be reduced to run fgfs, tweak
in-flight, dump new
Michael Bonar wrote:
MSVC6 has a Visio add-on that allows you to reverse engineer C code
into UML diagrams. Anybody have experience with it? I was thinking
of giving that a try to see what it looks like.
It probably looks a lot like UML generated automatically from C
code. :)
I've never
Curtis L. Olson wrote:
actually my guess is that due to the gear problem, it probably
crashes instantly so nothing will work at all with it.
Yup, that was it. Sorry, I've been ignoring this one. I recently
changed the default gear spring strength. But taildraggers have
different c.g.
Norman Vine wrote:
This method should also be *considerably* faster then the current
Panel code in that the actual updating of the instruments can be
done on a round robin basis
I'm not sure this will work as well as you think. The only way to
reduce the amount of work done is to re-render
Norman Vine wrote:
This used to be true but not with the current cards or on any NVIDIA
card with a current driver glCopyTexSubImage is FAST even without
using pbuffers
It's not all that fast. You still have to clear the back buffer and
you still need to do the memory blit into the texture.
Whee, here we go. :)
Steve wrote:
I think you have it wrong.
EVERY card implements GL_CLAMP because all that it requires is that
the texture coordinates are clamped to the range 0..1.
No. Check the spec, or the recent discussion on the DRI list. I
thought this must be the case, too, but I
David Megginson wrote:
On my system, I use procmail to sort messages into separate lists.
When someone crossposts to flightgear-devel and plib-devel (for
example), both messages end up in the flightgear-devel folder,
because that rule fires first, so it just looks like a duplicate
posting.
David Megginson wrote:
Last time I looked at swig, it was for creating bindings for native
libraries from include files.
Try
perldoc -f pack
perldoc -f unpack
Perl has excellent support for this kind of thing, once you get your
head around it.
BIG WARNING: The pack/unpack facilities
I've been playing with the new ATI linux drivers recently. It turns
out that they have a performance problem that gets tickled by plib.
Plib allows you to pick wrapped or clamped texture borders when you
create your ssgTexture. To get the clamping, it uses the original
GL_CLAMP mode, instead of
I wrote:
[snipped]
Can someone forward this to the plib list? For whatever reason, none
of my posts seem to get through there. Dunno if that's a sourceforge
thing or what...
Andy
--
Andrew J. RossNextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL
Jon Berndt wrote:
Also, Andy: which point does YASim provide to FGFS? Is it the CG, or
some other point?
It provides the coordinates of the origin, be that the nose or
centroid or FAA reference point or whatever.
Going back into hiding now; wake me up if you need me to move the
origins. :)
Erik Hofman wrote:
Jon Berndt wrote:
Well, to rotate the aircraft realistically the refference point should
be known by the 3D modellers, but that aside.
The rigid body rotates about the CG, not the aero ref. pt.
Even when in motion?
It seems to me there would otherwise be no need
David Luff wrote:
Jon Berndt wrote:
Well, to rotate the aircraft realistically the refference point should
be known by the 3D modellers, but that aside.
The rigid body rotates about the CG, not the aero ref. pt.
What about rotation (the taking-off one)? Surely in that case it rotates
David Megginson wrote:
1. Put the X axis origin at the published weight-and-balance reference
datum.
2. Put the Y axis origin at the centreline of the plane.
3. Put the Z axis origin [where? the ground?].
I'll just state my opinion again, and then keep my head down until
someone tells me
Fabien ILLIDE wrote:
David Luff wrote:
FWIW, the grey panel with the Radeon 7500 and the DRI drivers still
persists despite the patch to fix this behaviour with the ATI binary
drivers.
I jump onto this post to say that I've just see that I've got the same
problem with my new Dell
Jim Wilson wrote:
FWIW I'm also seeing a significant degree of what appears to be
z-buffer fighting with geforce2 at 24bpp. The c310-3d panel goes grey
at certain angles and the c172-3d and a4-yasim panels display a lot of
instability in the rendering (problems between layers in the
Jim Wilson wrote:
Right, the polygon offsets that I thought I rememebered Andy had
been adjusting for this issue seem to have introduced some other
problems though.
The way it worked was that the original code I submitted used a very
high offset number (because I'm using NVidia hardware too,
Jim Wilson wrote:
Michael would like to add an additional default view (a third, closer
tower) to the base package preferences.xml. I'm against it since we
offer the ability to add custom views and there's already too many
default views for my taste.
I'd argue that this is a UI limitation.
Carsten.Hoefer wrote:
Forgetting about all 'unsafe' situations in helicopters, do we have
one in flightgear? Is it possible to model one with the existing
flight models we use?
Not without a lot of code work. Helicopters have a bunch of effects
that don't exist in the current FDMs.
Things
David Megginson wrote:
configure:8649: checking for ftime
configure:8699: gcc-3.2 -o conftest -g -O1 -finline-limit=6
-finline-functions -D_REENTRANT -I/usr/X11R6/include
-L/usr/X11R6/lib conftest.c -lm -ljpeg -lmk4 5
/usr/local/lib/libmk4.so:
Curtis L. Olson wrote:
With the latest YASim changes, the J3 Cub won't converge for me (and
others.)
Confirmed. Sorry, I didn't test this one.
Any ideas?
No, sadly. A quick spot check shows that it fails for pretty much all
sane configuration changes. And the thing that *should* return it
I wrote:
Curtis L. Olson wrote:
With the latest YASim changes, the J3 Cub won't converge for me (and
others.)
Confirmed. Sorry, I didn't test this one.
OK, fixed. The model was almost converging, but wasn't getting close
enough to the threshold. It was oscillating around the right
Curtis L. Olson wrote:
Alex Romosan wrote:
after updating to the latest cvs, i can't fly the a4-yasim anymore:
For what it's worth, I can reproduce this.
Oddly, I couldn't; the A-4 worked fine. But I did notice a newly
induced failure of the (rarely used) Cessna 310 model. I gave it some
Curtis L. Olson wrote:
Heading hold seems to fail on YASim planes ... something seems to be
missing, or not quite happening right. I thing this was introduced
about the same time David implimented the vacuum driven AI and DG ...
Hrm... did a property name change, perhaps? Or maybe something
[bouncing discussion to flightgear-devel]
Adam wrote:
Andy Ross wrote:
Adam wrote:
As soon as I run ./fgfs I immediately get segmentation fault
- with no other errors.
John S. Coomler wrote:
I am also using Mandrake 9 and I too get the same segmentation fault
error
David Drum wrote:
I am compiling FG 0.9.1 on Mac OS X.
ld: Undefined symbols:
_CPSEnableForegroundOperation
_CPSGetCurrentProcess
_CPSSetFrontProcess
_CPSSetProcessName
[...]
I sent this to flightgear-users a couple days ago when 0.9.0 was out.
No response.
Unfortunately, the OS X port
Major A wrote:
There is another issue with the A4 though -- pressing shift-KP8 gives
a default view which is nicely out of the window, but the instruments
are no longer on the screen.
You mean that the view is looking too far up, above the level of the
instruments, right? Not that there's a
Norman Vine wrote:
Andy Ross writes:
I think you have to give serious thought to enabling this by default,
Great idea, got a URL for a native WIN32 version of rsync ??
Doing a google on rsync cygwin pulled up this post that claims that
it works normally out of the box. You have to build
Norman Vine wrote:
But in any case I don't appreciate programs that automatically connect
to the NET and I still want to have the default behaviour NO
networking without explicit authorization !
That's a fair point, although as long as we aren't transmitting any
data I don't see any ethical
Michael Basler wrote:
One ugly solution might be to provide just the rsync.exe, but I don't
know if this works (it would require the cygwin dll, at least). Plus
this might cause licensing troubles.
Why not? I can't speak to whether it works with (only) the cygwin
DLL, but there's nothing
Major A wrote:
May I suggest a straight-forward solution:
- For 2D panels, disable GL_DEPTH_TEST altogether.
No objections here. It wouldn't even complicate the code much at all.
The only downside is that the traditional 2D panels are essentially
legacy features. All current development
Curtis L. Olson wrote:
Do we know which source files are having problems with min/max under
cygwin?
My impression (watching from the peanut gallery) is that min and max
are useful functions that simply can't be used portably, not unlike
alloca or snprintf.
But in this case, is this such a
Major A wrote:
Sorry, I only said 747 because that was the only one I could run in
the broken build I used. I now fixed that one, it happens with all
2D panels, 172, 182, 747 (press P), etc.
I can confirm this. Layers on the 2D panels (but oddly, only the 2D
panels) aren't drawing over the
I wrote:
I can confirm this. Layers on the 2D panels (but oddly, only the 2D
panels) aren't drawing over the background with the current ATI
drivers.
OK, this turns out to be a trivial fix, although I still think it's a
driver bug. There are two calls to glPolygonOffset in the panel
Curtis L. Olson wrote:
I could easily be wrong since I've never messed with glPolygonOffset
myself, but it's my understanding that one of the problems with this
function is that the values you need to assign to the parameters can
be different across platforms to accomplish the same thing.
David Megginson wrote:
Major A writes:
- The autopilot in the 172 tries to keep the orange heading bug at the
top of the directional gyro, period. If you set the DG to the true
heading (as you would in the Arctic), then the autopilot uses true
Ever flown a (real) 172 across the
Erik Hofman wrote:
Now that your five minutes of fame are over, I'd like to ask you to
remove the creation of the yasim program in a default build, because
it has a lot of dependancy problems for me (IRIX/MipsPro).
First it needs all objects files from src/Main and libFlight.a from
src/FDM
William Earnest wrote:
js_demo.cxx:21: undefined reference to `jsJoystick::jsJoystick(int)'
js_demo.cxx:84: undefined reference to `jsJoystick::read(int *, float *)'
Recent plib changes have turned the joystick routines from an inlined
header file into a real library. You need to add a
Erik Hofman wrote:
I'll try to see if I can illiminate most of them by only adding the
YASim object files required by yasim-test instead of including
libYASim as a whole.
OK, I've checked in a Makefile.am that does exactly that. It still works
for me; is Irix happier?
Andy
--
Andrew J. Ross
Erik Hofman wrote:
I propose a small change in the Makefile which might make life a
little easier in the future, by defining SHARED_SOURCES wich hold
(indeed) all the files that are shared between the library and the
stand alone interpreter.
Indeed. I actually tried that first, but gave up
William Earnest wrote:
With the compile problems resolved, still getting a consistent
segfault just after Done reading panel instruments. The other
repeatable clue is that the fgfs window never appears.
I'm not aware of any current crashing bugs. Can you run it in gdb and
get a stack trace?
Martin Spott wrote:
Andy Ross wrote:
Probably most of you noticed last week that ATI has released a unified
linux driver package for all of their 8x00/9x00 cards. [...]
Wohoo, you made it into /. with this article. I would not wonder if this
boosts FlightGear popularity :-)
Yikes. My
I had some time today to play with YASim stuff. New things in CVS:
Fuel consumption has finally been implemented. It's pretty simplistic
and doesn't support stuff like tank selection, engine-specific fuel
feeds, inter-tank feeds (or fuel dumping), etc... But it seems to
work. It probably also
Martin Dressler wrote:
It was me, but unfortunetly I wasn't succesfull. The one problem is in
drawing lines. Cause we use polygon offset you must use polygons
instead of lines.
This isn't entirely a showstopper. Polygon offset works for lines,
but you have to enable it explicitly and there
Probably most of you noticed last week that ATI has released a unified
linux driver package for all of their 8x00/9x00 cards. I've been
wanting to try one of these for a long time, but have been a little
scared of the DRI drivers which are still maturing. This was a good
excuse to buy a cheap
Curtis L. Olson wrote:
Recently a very kind person donated some hardware to upgrade the
flightgear web/cvs/ftp/rsync/cvs server. I am respecting their wishes
to remain anonymous which is why I've avoided any hoopla.
Aw, c'mon. Can't we have just a little hoopla? I hate anonymous
donations.
Jim Wilson wrote:
Well this probably isn't very impressive. But here it is. First view
from the pilot's seat. Things are very rough at this point.
Oh, baby. Someone get some instruments in that thing. :)
One nit that occurs to me: looking at the horizon, it looks like the
view down over
Curtis L. Olson wrote:
BTW, Andy, how hard would it be to accept an initial airspeed for
the YASim models so we can do in-air starts with those?
Not hard at all. The only reason it doesn't is that, heh, I got
really confused about how to figure out the units and precedence
rules. Speed can be
Jim Wilson wrote:
What do the gear/compression-norm values in YASim represent? Is it
a distance or travel range fraction or something else?
It's a normalized value -- a fraction. A value of 0 represents full
extension, 1 is full compression. The actual length numbers can be
gotten from the
Roland Häder wrote:
But what about fixing-out some compiler warnings?
Most of those appeared with gcc 3.2, I believe. They don't look too
scary to me -- mostly C++ standardization stuff. I'm sure they'll be
fixed soon.
Scanning through it quickly, it looks like mostly David's code.
Sloppy
Roland Häder wrote:
fgfs: relocation error: fgfs: undefined symbol: __10c4_StoragePCci
Very complete bug report. Unfortunately, it's a FAQ. :)
The metakit library you linked when compiling against isn't the one
that is getting picked up by the shared linker at runtime. Try an
ldd fgfs to find
Jonathan Polley wrote:
I updated plib, SimGear, and FlightGear before rebuilding. I cleaned
everything on Windows because there were some changes to plib headers
(MSVC isn't always smart enough to properly handle header changes if
they are not in YOUR project). I haven't cleaned the MacOS
Jim Wilson wrote:
The origin location on the 747 and a4 were fixed (Andy?) as of
yesterday.
Yeah, that was me. I still say that the origin should be on the
airframe instead of inside the plane, but a promise is a promise. :)
Random note: how hard would it be to get the checkin account added
Erik Hofman wrote:
To be honnest, I don't think anyone would even notice if the Boeing
were tail scraping over the runway. For example, it is very comon for
F-16 to hit the runway with their ventral fins on startup or
touchdown. This is usually only noticed afterwards by the groud crew.
True
Curtis L. Olson wrote:
Cruising in the 747-yasim at 18,000' (altitude holding me steady) and
with throttle adjusted so I'm stable at 490 kts, I'm seeing a -3
degree pitch down (/orientation/pitch-deg)
This looks odd from an external view standpoint. It seems like we'd
want a slight amount
Julian Foad wrote:
Hey, it's slightly different! How about we scrap the differences
and the anomalies and combine them? To do so, I'd suggest:
If you guys are thinking of changing the way we do linear function of
a property value definitions in configurations, let me argue for a
slightly
Julian Foad wrote:
It seems silly to have the brake key slam on full braking power, if
it is to be used on the runway. No wonder the aircraft tend to tip
over or burst their tyres. Can I recommend this patch which sets the
all brakes strength to 0.5 and the individual left/right to 0.7?
Jim Wilson wrote:
After moving the AC3D model origin to where Yasim wants it (at the
nose) the aircraft rotates fine. (Note that it appears the gear still
compresses abit too much as when doing Curt's throw on the breaks at
40kts test, the nose comes very close to the ground).
Yeah, the nose
I wrote:
I need to get per-gear tunable spring constants and damping
coefficients working; the automatically generated ones are almost, but
not quite, good enough for all cases.
Well, that was easy enough. You can now use spring and damp
attributes on gear objects to modify the default ones
Jason Viloria wrote:
Can anyone please tell me the state(or existence) of development on
glass panel cockpit instruments on flightgear please.
There's nothing working inside of FlightGear for this yet, but the
OpenGC project (www.opengc.org) is available as a stand-alone app.
You run it on a
Julian Foad wrote:
David Megginson wrote:
it would be nice if the engine were its own subsystem and we could
mix-and-match engines and FDMs
Well, I suppose it needs someone to show how the two aims can be
compatible. But it's not easy; it would require becoming familiar
with both
Roman Grigoriev wrote:
ok it's done at startup but if we want to have landing lights moves
we have generate second texture coordinates in realtime please give
me hint where in flightgear it can be done? in tileentry?
I'm not the right person to answer questions about the scenery tile
Tony Peden wrote:
BTW, you will rarely see the c.g. used as a reference point for
dimensions on aircraft. First of all, it moves in flight. Second of
all, it's very difficult to actually point to its location.
That's my intuition too. David is correct, though, that most
lightplane POH's use
Jim Wilson wrote:
When the 3D model origin is set at the nose or cockpit, the aircraft
is too far back on the runway at startup. So far back that the main
gear is not on the pavement. It looks stupid.
Ah, now I think I understand what you mean. I agree, the model
placement looks dumb. But
Burrito Jack wrote:
Is fuel consumption modeled in yasim, or will it ever be?
Someday. :) Right now, you can use --prop:/sim/fuel-fraction=0.2 to
get an appropriate landing weight. Really, this would be very simple.
Like I've said, I'm lazy.
To be honest, I don't usually fly cross country in
I wrote:
Jim Wilson wrote:
How hard would it be to have a property that toggles hotspot
visibility? It'd be nice to be able to turn it on and have yellow
rectangles show up on the hotspots...
That's not a bad idea.
It's actually an astoundingly good idea, and implementable over lunch
to
Michael Basler wrote:
Andy Ross wrote:
Try the attached patch, which predicates the boxes on the
/sim/panel-hotspots property. I mapped a toggle event on this to a
spare joystick button, and had fun. :)
Up until we'll have that pretty menu system soon ;-) would it be hard to
bind
Manuel Bessler wrote:
BTW: What is the difference between Speedbrakes and Spoilers?
Typically spoilers refer only to flaps on the top of a wing. They
spoil the lift generated and allow the plane to fly at a higher angle
of attack for the same lift, and thus descend more steeply (or remain
on
Jim Wilson wrote:
That's a little too small to resolve differences at 16bpp. Try the
patch below. It decreases the lifting substantially. You will see
a slight increase in z-buffer flickering but it isn't bad.
Has anyone tried offsetting the lights in the direction of the viewer?
While this
Cool, someone's playing with the 747. This model hasn't had a lot of
tweaking yet beyond the engine thrust bugs that Jim Wilson dealt with
a few months back.
Manual Bessler wrote:
Here are a few things I wanted to ask about the 747-yasim:
Does it model the thrust reversers ?
What about
Curtis L. Olson wrote:
Speaking of gear modeling in the 747-yasim, have you tried getting the
aircraft up to say 40kts. taxiing and then hit the brakes ... there is
clearly something going on with the 747 gear modeling that is not
physically possible ... best seen when viewed from the chase
Curtis L. Olson wrote:
Speaking of gear modeling in the 747-yasim, have you tried getting the
aircraft up to say 40kts. taxiing and then hit the brakes ... there is
clearly something going on with the 747 gear modeling that is not
physically possible ... best seen when viewed from the chase
Julian Foad wrote:
For those who were wondering why it seems intermittently broken, what
seems to be happening is the 2D panel hotspots are always active as
well, and they pick up the mouse clicks as well (or instead, if the 2D
hotspot area overlaps a 3D hotspot area).
Are you sure? I
Julian Foad wrote:
Well, I'll put it this way: If I turn the 2D panel on and off with P
while flying --aircraft=c172-3d, and note where a particular button
is, and then turn it off so that only the 3D panel is visible, I can
still click where the 2D button was as well as where the 3D button is
Jim Wilson wrote:
It isn't tedious at all, we can offset the origin to where we want
without messing with the ac file *and* it won't affect the
animation.
Cool. Uh, how? :)
Having the FDM origin at the center of gravity should improve the
appearance of the 3D modeling since pitching of the
Jim Wilson wrote:
How hard would it be to have a property that toggles hotspot
visibility? It'd be nice to be able to turn it on and have yellow
rectangles show up on the hotspots...or something like that. Thinking
about making hotspots to control some of the 3D instrumentation.
That's not
I give up; I withdraw the HUD patch. Too many people want the code to
stay the same to make it a good basis for doing 3D cockpit work, even
with the compatibility hook in place. (Although I suspect that if
people tried it, they might change their minds). I'll maintain it for
my personal use, of
Norman Vine wrote:
Andy Ross writes:
Sure there is. But the ladder will only work at 1024x768 with the
default view direction and field of view.
The current HUD ladder works fine at all resolutions with all view
directions once you accept the fact that it is a 2D Overlay instrument
David Megginson wrote:
To simplify things, I've just committed a base-package patch to bind
zoom-in to '+', zoom-out to '-', and return to default zoom to '='.
Ooh, this brings up a good point. Is there a place to store a default
David Megginson wrote:
I have a feeling that we won't have good, free geodata for the rest
of the world until the U.S. decides to provide it for us,
Actually, wasn't there a shuttle mission about two years ago which did
a high-resolution radar survey of the whole planet? I remember
reading
I wrote:
Actually, wasn't there a shuttle mission about two years ago which did
a high-resolution radar survey of the whole planet?
Duh, that's what the SRTM link is about on the page Norman sent.
I followed through to the project webpage at JPL
(http://www.jpl.nasa.gov/srtm). In their words:
801 - 900 of 1282 matches
Mail list logo
