The matrix doesn't define some cells, which are actually used
in the multiplication. That makes the result unpredictable.
I have no idea if 0.0 is the correct value for these, but
garbage is hardly the correct value either. Should some of them
be set to 1.0?
Think my brain is getting clogged with matrices :-). Well I've got the funky
orientation offset bug out of the model code. In the process the model.cxx
got optimized a bit. At some point we'll need to liberate model.cxx from the
viewer class, but it is no longer hard coded to access the "pilot view" to
get it's data. Instead it uses whatever the "current" view happens to be. I
may try and do that final bit of having models rotate independant of the view
tomorrow night, or start right in on the viewmgr and get a tower view up and
running. You guys have any preference? My brother's family is coming to
visit for a few days so what I don't get done tomorrow night probably won't
get done until after the weekend.
The compiler complains about too long names for instanciated templates
that result in name truncation. There are warnings but finally it ends
with a fatal errors. I found that ignoring the warning cure the
problem.
as a follow-up of my previous message, I found that in panel.cxx, function
const char *FGTextLayer::Chunk::getValue () const, there is the use of a
member variable _buf that seems to be uninitialized.
When the loop starts, n.type is still undefined, so the while statement
depends on unitialized garbage. The input operator cares for the [End]
bracket anyway (returns if the first character is a '['). So it is safe
to check for it after reading the line and break if necessary.
The first hunk might not be necessary, but the light_coverage property
was the only one that wasn't explicitly defaulted, which is unfair. ;-)
The second hunk adds the missing initialization to the init routine.
This is necessary, because (unlike the material entries from material.xml)
the generated light entries don't get the light coverage set. Yet
obj.cxx:795 reads this information out fot every leaf, although not needed
in the case of lights. Avoiding this isn't worth the trouble.
The last hunk sets the missing normal_index. The POINTS branch in
gen_leaf was always called with this int_list empty, which made the normals
handling use data garbage.
It seems that the airport database was changed some day and the End?Flags
changed from floats to strings. The database definition, though, was not
adapted and still created number entries. Reading out these flags led to
access to memory, that was never initialized. While it didn't cause crashes
during normal use, it actually caused one when I ran fgfs in ddd. Seems,
that the concerned memory region wasn't zeroed out then and hence uncovered
the bug.
Of course, the runways.mk4 database has to be re-created with the new
definitions.
Fix FGViewer::update so that pitch offset and goal pitch offset work
together nicely (the offset was snapping to 90/-90 when only one of
the two was changed).
Viewer improvements from Jim Wilson:
These files get the 3d cockpit working and fix a few issues in the viewer
code.
XYZ offsets are now defined as follows: X -left/right+ (along wing axis), Y
-up/down+ perpendicular to the aircraft, Z is -in/out+ the aircraft's body axis.
I've also done some cleaning up of unused and mostly unusable interfaces,
added commentary to the *.hxx, combined together some duplicate code and
eliminated a couple unecessary operations. I also moved what was left of the
"protected" zone to "private" since we aren't subclassing this anymore.
(mainly in src/Input/input.cxx) will make src/GUI/mouse.cxx obsolete
and bring the mouse into the same input system as the joystick and
keyboard. This is just preliminary work allowing, covering mouse
clicks (no motion yet), and it actually crashes on a middle or right
click.
The new mouse support is disabled by default until it become stable;
to try it out, you need to configure --with-new-mouse.
for fuselage Surface objects. If the fuselage wasn't aligned perpendicular
to the Y axis, the matrix wouldn't be orthonormal. Since all of, perhaps,
three aircraft have ever been built this way, it's doubtful I would have
found this as a bug report. :)
