Jim Wilson wrote:
Hmmm...I don't remember ever having to to look up to see lights when running
the voodoo card.
When you say very high, how high do you mean?
It looks like about 2m to me. Is it possible that you guys are just
using different aircraft? David tends to hang out in the Cub and
Julian Foad wrote:
Andy Ross submitted a patch which changes the way the HUD works.
Norman Vine wants the old behaviour to remain available as an option.
I really shouldn't get involved in this, but ... well ... here are my
views [... views snipped ...]
Sounds good to me. I'm still not quite
Norman Vine wrote:
Andy Ross wrote:
There is no way to keep the old scaling scheme and be
view-independent at the same time, sadly.
If this is true then there is no way we can maintain a 2D overlay,
library which is what the existing HUD code is, with Andy's changes
Sure
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.
Certainly this could be flipped on and off. Actually, there's a
vestigial if(1) {...} in
Norman Vine wrote:
I submit that your patch is an additional mode and should be presented
as such rather then BREAKING existing behaviour as IMHO is all to
often what happens when someone decides to get involved with a piece
of the code.
Oh dear, not again. For the record (and I really tried
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
Norman, this isn't constructive. Here are some things I'm quite
certain you don't want
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 an old 3D HUD patch to the
Frederic Bouvier wrote:
What do you think of that (translated from french) :
Left : integral part
right : mantissa
Actually, in English that is ambiguous. The term mantissa is
already used to refer to the scalar multiple in a number with an
exponent. That is: mantissa * base ^ exponent.
Richard Bytheway wrote:
We really ought to sort out the ability to disable *any* console
output after initialisation on Windows...
Is it maybe time to revisit the priority of most of the log messages?
I mean, the vast majority of these things are debugging output for
code that is mature and
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.
We could try playing games with
David Megginson wrote:
Curt's problem, though, is that his deletion code has to do a linear
search in the parent for each child node to remove it; I assume that
plib's internal code just iterates.
Ah, never mind then. :)
Yeah, O(N^2) deletion behavior with thousands of nodes is bad, and no
Curtis L. Olson wrote:
I just added support for generating taxiway lights into terragear
(with some corresponding changes in FlightGear) so I guess someone is
going to have to regenerate the airports again. :-)
How about doing the light generation at tile load time, instead of
generation time?
John Check wrote:
What it is is that when electrical system modeling was added it
affected planes for which no electrical system was added. I went
through and added the markup to include the electrical.xml from the
default 172 to all the variants, but never did the non Cessna planes.
John Check wrote:
Latest cvs build falls down with:
pt_lights.cxx:304: `cout' undeclared (first use this function)
You're using gcc 3.2 I assume? It's a namespace issue. The C++
standard library naming is stricter now. You need to use std::cout,
or insert a using namespace std; above the
diff -u -w -r1.31 main.cxx
--- main.cxx17 Oct 2002 04:34:32 - 1.31
+++ main.cxx19 Oct 2002 18:38:22 -
@@ -141,16 +141,16 @@
typedef void (APIENTRY * PFNGLPOINTPARAMETERFVEXTPROC)(GLenum pname,
const GLfloat *params);
[Er, oops. The last one had the patch but not the text. Apologies!]
OK, looking more carefully, I think I see how this is supposed to
work. Because not all OpenGL implementations export the
PointParameter functions, Curt is using function pointers and the
GetProcAddress stuff.
This is fine;
John Check wrote:
Is this last line correct?
Uh, no. :)
Sorry. I don't compile on a windows box, so that part of the change
was blind.
Obviously, the actual names of the symbols used isn't important. You
could just as easily use GL or fg, or fgfsgl or whatnot so long
as it's consistent and
I grabbed current CVS last night for the first time in a while, and
got bitten by a bug with the 3D panel support. Has anyone else
noticed this? What happens is that on an aircraft with no 2D panel at
all (a4, c172-3d, but oddly not the j3cub), the sim crashes at
startup. The first problem was
Curtis L. Olson wrote:
it seems to be more than a simple coordinate system difference,
unless JSBSim/YASim swap X/Y axes or something strange like that.
Could be a bug, too. What exactly is the behavior you're seeing? The
way the code in steam works is to look at the Y and Z pilot
Curtis L. Olson wrote:
Question: for a particular source file, if a person contributed a
minor patch or tweak to compile on a new platform, does that person
now have a full say in the future of that source, or are they giving
their changes to the author of that file to be placed under the
Alex Perry wrote:
There is a subtle distinction, which essentially means that, since
you do still have the copyright, people who retrieve the code also
have the right to sue you.
It's even more subtle: the right to sue you doesn't go with the
copyright. The copyright is a right that *you*
Tony Peden wrote:
Well, I tried to compare the two, but got this for the yasim c172:
YASim SOLUTION FAILURE:
Are you sure you have current code and base package? I haven't looked
at the 172 in a good while, and not much has changed. Do the other
YASim aircraft work for you?
Andy
--
Andrew
Curtis L. Olson wrote:
The JSBSim drives the ball in a reasonable way, as does this other FDM
I'm playing with. However, the scaling is about an order of magnitude
different between the two, even though they supposedly report the
accels in the same units and are modeling the same aircraft.
Alex Perry wrote:
I don't see a real benefit of changing FGFS from GPL to LGPL ...
* The people who don't like GPL probably aren't much happier about LGPL
* They (or we) can add a shared-memory tunnel in SimGear for properties
* Most proprietary extensions can simply coexist as separate
David Megginson wrote:
Remember Knuth's (?) warnings about premature optimization, though.
Amen. This blog says Knuth got it from Tony Hoare:
We should forget about small efficiencies, say about 97% of the
time: premature optimization is the root of all evil.
Julian Foad wrote:
I thought it was the other way around: that most Linux filesystems (by
which I mean ext2) and NTFS had 1K or 0.5K blocks, and that Windows
FAT filesystems had big (generally 4K to 16K) blocks.
Nope, 4k. The underlying disks have 512 byte blocks (all IDE and most
SCSI, at
Simon Fowler wrote:
One thing to note here is that all this cache take up RAM, and will
be dropped on the floor as soon as there's any memory pressure.
Right, which is why I was careful to cite numbers that reflected
actual disk I/O, and not cache performance. Even hitting the disk,
Arnt Karlsen wrote:
..wee tweak:
for i in $( seq 100 ) ; do
touch $i
done
Cute. You learn something new every day. I've never noticed that
utility. I have a vague memory that there is some bash syntax that
does a similar thing, too. And the $(...) syntax was new for me too
-- I would
David Megginson wrote:
Alex Perry writes:
Why can't we stick it into the scenery directories, but one directory
up from the tiles, so we have one file per 10degx10deg of planet.
That should ensure that FGFS doesn't need to load all that many files,
and just having the one file in the
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 manitude less at least
True, but
David Megginson wrote:
I cannot say. One thing we're not modelling yet is nosewheel
shimmy:
Does this really have to be modeled, per se? Until we get support for
force-feedback rudder pedals and seat cushions, the only thing we can
reasonably do is play a sound. That can be done already
Jim Wilson wrote:
How do they work in real life? It seems that animation shouldn't be
necessary.
I got to see a 2-light PAPI up close at Fishers Island*, NY once.
It's an astonishingly simple device. Basically, it's a box with a
bright white interior. At one end is a lens. At the other (on
David Megginson wrote:
Frederic Bouvier wrote:
I think your are making the too rapid assumption that
an iterator is a pointer to an element.
Don't iterators override the '+' operator if they're not just
pointers?
Indeed. That's the whole genius (madness, whatever) behind the idea.
Many
Bernie Bright wrote:
Only random access iterators support the '+' operator. Fortunately
std::vector and std::deque provide just such iterators.
I thought there was a variant that supported incrementation but not
decrementation. You don't need the full-on random access variant in
this case.
Frederic Bouvier wrote:
I made a french translation but unfortunately, accented characters ( e
acute or a grave for instance ) are not present in the current font. I
think the problem will show up for several languages. Should we have
to provide a specific accented font for languages like
Richard Bytheway wrote:a
As mentioned in the Sig11 FAQ (link above), ensure that all the
hardware in the PC is the correct spec, and that nothing is
overclocked. Try underclocking as a possible workaround. If your RAM
is on more than one stick, try removing different parts of it.
Oddly, that
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 single point of
intersection. Worse, they don't always point down. Even
Melchior FRANZ wrote:
1 would fix my problem. BUT: 40 only breaks the fog in the scenery,
while it works well for the instruments. So I suggest to let
POFF_UNITS be 40 but to reset the PolygonOffset to -1 or zero after
having drawn the instruments. This should also work for all other
cards.
Norman Vine wrote:
For example the a4 behaves differently then the c172 in this
respect. Discover what is different and the lighting problem should
be 'illuminated'.
Curtis L. Olson wrote:
People who understand the opengl lighting model better than I do
might notice that I haven't
Curtis L. Olson wrote:
When you say moved panel rendering into the main scene graph, do you
mean [...] or do you mean the panel rendering code get's executed as
a call back from some ssg node [...] ?
I mean that one. :)
There's a tiny FGPanelNode ssgLeaf class that wraps an FGPanel
object.
I got a chance to try the dynamic scenery last night (in lieu of
implementing the gear bounce/damp tuning for Dave Perry -- sorry).
Wow. Simply stunning. :)
Abject praise out of the way, here are the nits:
The cowbox is too small. At only 1m high, it's really a more
appropiate size for a
David Megginson wrote:
Norman Vine wrote:
Win2k PIII 733 256meg Geforce2 GTS 32 meg Latest certified WQL GFX
drivers from NVIDIA at default startup location no HUD no Panel
Latest changes~17fps
your original code~32 fps
no dynamic objects ~75fps
Here's what I get
David Megginson wrote:
Norman Vine writes:
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
I saw a pretty-nice
Curtis L. Olson wrote:
I'm not claiming we are currently optimal, but you also need to
consider that by grouping your low level structures into larger
chunks, you reduce the ability of the scene graph to do an early cull
of non-visible stuff. Making larger chunks needs to be balanced
Gouthas, Themie wrote:
I dont think the alpha sorting code was ever comitted, so currently
I dont beleive PLIB will alpha sort.
I'm not sure this is a great idea in any case. There are a *lot* of
these objects, and doing an NlogN sort of them (with attendant
geometry processing to get the
Victoria Welch wrote:
No jstest or jscal here and I have yet to track them down for
something other than SuSE or Debian (or a tarball that has be be
compiled into the kernel...)
These are userspace test programs, not the kernel driver. They really
should have been installed with your
Jim Wilson wrote:
Was in sound card hell myself a few nights ago, so I can relate.
Finally decided my time was worth something and went out to buy an
sblive
You weren't by any chance trying to make the built-in sound on a KT333
motherboard work, were you? I got bit by exactly this problem.
Erik Hofman wrote:
Today I've sent some new textures to David (which he hopefully will
commit somewhere in the next weeks). But the result is such that I
want to let you know about it:
Wow! This is magnificent. I've always hated the city texture (too
yellow, too nondescript, maybe the scale
Dave Perry wrote:
I have continued to work with the dc3.xml for yasim and some of the
numbers in the original file seem inconsistent with the 3D model.
Here are my questions:
The model and YASim description don't agree exactly. The biggest
difference is (I think) the location of the origin.
Frederic Bouvier wrote:
And what happens with deltas and positions when you will lose UDP
packets ? How will you restore the correct position or orientation ?
Perhaps, from time to time, it will be good to send absolute positions
to resynch.
Yes, this is a requirement. Sending unreliable
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 general-purpose algorithms like
Curtis L. Olson wrote:
My initial speculation is that the position of my eye is an important
factor that isn't addressed by the simple theory, but from the simple
theory, I don't see how that could be possible.
One nit is that the simple theory only works for small mirrors (large
curvature
Jonathan Polley wrote:
Jon Berndt wrote:
Just because something *can* be done doesn't mean it *should* be!
Actually, I was going to say that it was another solution in search of
a problem.
I honestly thought it was a joke, but the website looks serious enough
to believe. Good grief.
But
Martin Dressler wrote:
I wan to draw lines in instruments layer. I made a new subclass of
FGInstrumentLayer and in draw method I do
glDisable ( GL_TEXTURE_2D );
glBegin(GL_LINES);
glVertex2f(-100,0);
glVertex2f(100,0);
glEnd();
but it doesn't draw anything. But when I
Curtis L. Olson wrote:
I had someone recently comment that they thought the glide slope
needle was too sensitive in FG. Can anyone comment on this?
I think the glideslope needle is too sensitive in FG. :)
I don't have any harder evidence either, but I'll throw in my 2ยข
anyway. I've been
I've been doing really well recently with my A-4 landings, so I wrote
up a putative Flight Operations Manual to record the stuff I've
learned:
http://www.plausible.org/a4-ops/
Obviously, I've never actually trained with the Navy, so lots of this
is guesswork based on data points I've picked
Dave Perry wrote:
Attched find an xml file dc3.xml that includes edits that allow
accelleration on the main gear and relativly easy wheel landings.
With these changes, I can leave the tail wheel unlocked for take-off
and landings.
Very cool. I'll try it as soon as I get home.
3. I moved
Norman Vine wrote:
Following is IMHO a good explanation as to why having the camera a
node in the scene-graph is not 'necessarily' a 'good idea'
Which is a good point in theory. Their basic idea is that the scene
graph specifies data, and you interpret that data via a camera.
These are two
Curtis L. Olson wrote:
But to your other point, I agree that we should start looking into
failure modes. This is one big un-addressed issue. I could make up a
list of interesting failure modes if anyone was interested.
This could actually be done with minimal C++ code. Picture a failure
Curtis L. Olson wrote:
I haven't been following this thread as closely as I should have been,
but there should be no reason why we'd need to have the camera in the
scene graph. I think we just need to be smarter about how we
structure the transforms.
That was my original suggestion: put the
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, I think you misunderstand the
issue. Just adding an offset to the camera is what's already being
done, and
David Megginson wrote:
Thanks for the info. I'd be reluctant to put together an
Input/Joysticks/Saitek/X45.xml file that I couldn't actually test. If
you have a chance to hobble one together some time, I'll be very
grateful.
I was afraid you'd say that. :) Here is an X45.xml file that I've
Arnt Karlsen wrote:
..one idea; try make the effectiveness'es a function of the propwash,
or thrust initially, and from each engine. May help to get a feel for
it, I'm not that sure this is the _right_ way to model it. Negative
thrust (say on decent/approach, does not need negative prop
David Megginson wrote:
Please send me your bindings for your own device. Under Linux, you
can find the device name with a command like.
This is a great feature. Very cool.
Here are button and axis assignments for my Saitek X-45 under Linux.
My actually joystick.xml file is in a terribly
Arnt Karlsen wrote:
..(during the Falklands War, the Britts tested refuelling of Harriers
and Sea Harriers, from ships, in-hover refuelling, believe I saw this
in Air Progress magazine in the mid 80'ies.)
I think what you're remembering is the Sky Hook gadget that was
developed but never
Jim Wilson wrote:
When I get some time I'll run further tests and maybe come up with a
patch to avoid this sort of glitch. It would be helpful if someone
happened to know why this gap happens in the scenery data sometimes.
I'm sure Curt can talk in more detail, but my guess is that this is
Major A wrote:
has anyone recently used the FDR? I've just recorded a couple of
flights with the a4-yasim, and whenever I try to play back the
recording, fgfs dies with a segfault.
dumb-question
We have a FDR feature with playback???
/dumb-question
Andy
--
Andrew J. Ross
Curtis L. Olson wrote:
I agree that random/periodic bugs are insidious and frustrating and
makes the software look like crap; therefore we should have a
'culture' of agressive pursuit of these problems. But, unfortunately
I can't replicate your particular problem here which makes it
This is great stuff; apologies for forgetting to respond yesterday. :)
Dave Perry wrote:
I was able to get good control (vtab effectiveness) and early tail up
(htab effectiveness) with both values at 2.25. It was easier with
both values at 2.5. I then shot a number of touch-n-goes using
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), and has the same
Norman Vine wrote:
To experiment I believe all you should have todo is change the value
for 'center' in prep_ssg_nodes( vis, up, center ); in tilemngr.cxx
to reflect the 'offset' you want.
No, that won't work unless you can guarantee that the offset value
will always be within ~100m of the
Dave Perry wrote:
1. If the tail wheel is not locked, I find it much easier to take off
after removing the coupling of the rudder with the brakes for both
main gear from the dc3.xml.
I'd be happy to junk this; David always hated it anyway. It was
basically a hack to fix a problem I didn't
I spent some time over the weekend struggling with the jitterbug
(sorry, couldn't resist). I haven't fixed it, but I have pinpointed
the issue.
In essence: yes, it's a precision problem; but no, Jim's calculations
aren't the problem. The problem is actually the organization of the
scene graph.
David Megginson wrote:
So, Andy, here's your challenge -- you wrote YASim to prove how small
and simple an FDM could be; how about showing us how small and simple
a JavaScript implementation can be? I'm sure FlightGear isn't the
only project that would benefit.
Yikes, don't tempt me. You
Jim Wilson wrote:
Andy Ross wrote:
But I also goofed and checked in some of my private changes. The
eyepoint is slightly higher, allowing the pilot to look straight
down the nose as I believe is true for the real aircraft (it
radically improves visibility at high AoA's).
You probably
Jim Wilson wrote:
One thing I'm wondering is if we can do away with the background
texture in the 3-D panel. Do we need it or can the backplane always
be part of the model? Not sure if this would fix the problem with the
3-D model/instrument or not.
There's no real need for the panel to
FlightGear folks: I just checked in a nice Helvetica.txf into the base
package. Before you can use this, you need two things. The first is
a trivial patch to gui.cxx that allows for setting the default font
via properties (while leaving the original default in place). In
src/GUI/gui.cxx, line
Jim Wilson wrote:
Andy Ross said:
If the FDM points left, the cockpit will point left by the same
amount. Jitter from the FDM would cause the *scenery* to jitter,
not the cockpit.
No it would not. The scenery is too far away. Further pixels require
bigger values to shift. Distance
Jim Wilson wrote:
David Megginson [EMAIL PROTECTED] said:
On that point, I've tried your patch and it works, but the YASim FDM
is then (inexplicably) frozen. Is it working for anyone else?
This is a bug that seems to be related to some sort of memory
corruption. I've seen it off and on
David Megginson wrote:
Erik Hofman writes:
-rw-r--r--1 erik user 648823 May 12 2001 js-1.4-2.tar.gz
-rw-r--r--1 erik user 1046117 Mar 13 19:12 js-1.5-rc4.tar.gz
What does everyone else think?
I dunno. That's awfully big. JavaScript isn't a terribly big
Curtis L. Olson wrote:
I would argue that if we do embed a script interpreter it should be
really small, tight, and light weight.
Amen. :)
It's possible that the source for the actual interpreter is much
smaller than the full package, though. JavaScript implementations are
likely to be aimed
Jim Wilson wrote:
Setting all the view offsets to 0 I was able to prove that the
position/rotation matrices generated on the model and the camera are
numerically identical. Here's a sample from the dump:
Oooh, but they're not! Take a really close look at the two position
vectors (the last
Jim Wilson wrote:
Those are from two different iterations. I was just proving that the
viewer and model were running on the same data, as it had been
suggested they were not earlier. The pairs within a single iteration
match (this is the same data I posted earlier):
Yes, but even between
David Megginson wrote:
Speaking of taunting, do you have any ideas about the problem I
mentioned earlier -- that no text shows up on the radios in your new
3D panel patch? It's the only thing stopping me from committing it.
None yet, I need to get home and try it. Nothing looks suspicious;
Curtis L. Olson wrote:
I should mention before we get too far that glPolygonOffset is not
always consistantly implimented across cards/drivers.
Is that really true anymore? I know it used to be true ~5 years ago
in the era of QuakeGL, but today things are really quite stable.
The
[Cross-posted to the plib list, as this isn't entirely FlightGear
specific. Dunno if that list allows posts from non-subscribers or
not.]
The recent discussion about fonts got me interested in actually trying
something, so I put together a perl utility that generates an
antialiased Glut .txf
Sebastian Ude wrote:
What you generated are neither GLUT bitmap nor GLUT stroke fonts (the
only place where you usually find *these* fonts is the GLUT sourcecode
!), but TXF fonts / textured fonts / font textures. These fonts have
hardly anything to do with *GLUT*.
Clearly I'm ignorant of
OK, the attached patch adds character width support to the fnt
library, allowing it to handle glyphs whose logical width (distance
along the baseline to the next character) differs from their physical
width. Characters like the slash have this property, as do many
italic glyphs.
The current
Steve Baker wrote:
Can we add this tool into PLIB in the 'tools' area? It would be a
marvelous addition.
All yours. As I pointed out, though, it's definitely a tool of the
duct tape and fishing line variety. :) It expects to find a
ghostscript interpreter and ImageMagick's mogrify program
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
orientation of the aircraft is bolted to the FDM orientation. If
the FDM
Curtis L. Olson wrote:
It seems strange that everything else in the cockpit and 3d model of
the aircraft is perfectly stable and only this one instrument is
jittery.
Actually, the whole cockpit is jittering. The ball just has more
high-frequency information to catch your eye.
The panel
David Megginson wrote:
1. Can you post a copy of your modified base-package files
(a4-yasim-set.xml and a4-blue.xml)?
The -set files don't require any significant changes -- just remove
the panel entries and that's it. The model files for the A-4 and
172 are attached. All they needed is a
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 tried the antialiased fonts in KDE, WinXP or recent versions
of Gtk+?
Jim Wilson wrote:
Hmmm...I wonder if this relates to some of the effects I've seen
recently with the delta time and fdms. If you could put up a
separate patch for this (before the massive checkin :-)), I'd like
to run some tests to confirm. BTW, thanks for tracking this down.
This is what
OK, as promised, I have the fixed 3D panel support ready for testing
(http://plausible.org/andy/vpanel-20020624.tar.gz). Changes include:
+ The panel(s) are now an first-class SSG node inside the aircraft
scene graph. There's a little code added to model.cxx to handle the
parsing, but most
Jonathan Polley wrote:
I cannot redirect stderr via 'command 2 file' on my Mac, so the easy
solution was out. I did find that the following command works:
Rubbish. Sure you can. You just have to run a real shell. :)
Basically, this is a long-standing misfeature of csh, which never
existed
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 \
-fn '-sgi-sorority-medium-r-normal--40-*-*-*-p-*--ascii' \
Right, but this only gets you a copy of the X11 bitmap
This looks fantastic. I think this may be the first working gyro ball
in a PC simulator cockpit. At least, I haven't seen one anywhere
else. :)
On question, unrelated to the ball actually, is exactly what we're
trying to simulate. You seem to be aiming at an A-4C cockpit, but the
aero model
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 for
the labels, there
Jim Wilson wrote:
This looks a lot better. Just checked in a start on some adjustments
to the cockpit geometry and a bezel for the attitude ball. How sure
are you that the ball is supposed to be 6 in diameter? It looks to
be about 4 in every picture I've seen (but those can be deceptive).
901 - 1000 of 1282 matches
Mail list logo
