to 10m after takeoff, but that doesn't really make sense any more,
especially if models are going to have interior views. Is there any
real saving in pushing the near plane out anyway?
was some confusion between degrees and radians which would lead to a huge
goal_view_offset value. The display would sit and spin for a *long* time
trying to wind it's way up to this large value.
difference between the two is this: A sample is file related and sound
is a authonomus entity. This means you can have several sounds pointing
to a single sample. In that case, just one sample is loaded into memory.
The advantage is you can play the same sample with different pitch or
volume, but with just one sample loaded into memory.
To fully support this there is a new fucntion call:
FGSimpleSound *sample = new FGSimpleSound("filename");
mgr->add(sample, "name");
should be replaced by:
FGSimpleSound *sample = mgr->add("name", "filename");
But the old behaviour is still supported with one minor change, sounds
with the same name aren't supported anymore.
Erik
Actually, I think I'm off the hook here; the problem is pre-existing.
What's happening is that the x/y offsets enter the modelview matrix at
line 346 in the current panel.cxx. But note that the same
transformation also occurs before each instrument rendered at line
403. What's happening is that the instruments are double-translated
relative to the background.
Unless I'm not understanding something, the one inside the instrument
render loop looks unnecessary. Removing it fixes the issue and
doesn't cause any bugs that I can find. It also fixes a bug where you
could scroll the instruments on top of the 3D panel, where the offsets
are supposed to be ignored. :)
Attached is a new panel.cxx which fixes that bug, and substantially
simplifies the virtual panel code (the matrix inversion that I thought
was needed wasn't, but there were some offsetting scale bugs that hid
the problem).
These changes add to the "Add Waypoint" dialog so that you can see the entire
list in the pui dialog that you are adding to. Also made some minor changes
so that the autopilot is now activated (toward first waypoint target heading)
when a waypoint is added.
command will save *all* properties, rather than just those marked as
archivable. This feature was requested by Tony Peden to make it
easier to write documentation on the properties, but it should also be
useful for debugging. There is currently no default binding for the
command with the write-all parameter set to true.
What the attached patch does is map your panel definition onto a (non
z-buffered) quad in front of your face. You can twist the view around
and see it move in the appropriate ways.
Apply the patch (let me know if folks need help with that step), and
then set the /sim/virtual-cockpit property to true. You can do this
on the command line with --prop:/sim/virtual-cockpit=1, or via the
property picker. Bind it to a key for fast toggling if you like.
The default bindings don't allow for "panning" the view, so you'll
have to modify yours. These are the mappings to my joystick's hat
switch, for those who need hints:
<axis n="6">
<desc>View Direction</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
<axis n="7">
<desc>View Elevation</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
While the current implementation is happy with just plastering the
panel's notion of "screen" into the 3D world, this is actually more
general. Each panel can, in principle, have it's own coordinate
system, and you could build a cockpit out of a bunch of them. The
mapping is specified by providing a 3D coordinate for three corners of
the quad the panel should be mapped to; this should be pretty simple
to work with.
All that's needed for a perfectly general solution is a convention on
where to store the information (a cockpit xml file, or put it in the
aircraft -set file, or...), and some work on the panel's coordinate
system conventions (some of which don't coexist very nicely with a
generalized 3D environment). Combine that with a plib model for the
non-panel interior of the cockpit, and we're golden.
I'm actually really pleased with this. It worked better and more
quickly than I could have imagined, and impact on the surrounding code
is quite light -- a few property tests only. But some stuff is still
missing:
+ No equivalent work was done to the HUD, so it still displays
incorrect headings when the view changes. The use of pixel
coordinates deep in the HUD code is going to give me fits doing the
port, I sure. It's not nearly so well put together as the panel
(where I just changed the setup code -- none of the rendering code
changed at all).
+ I forgot that the panel was clickable. :) Input events still have
the screen coordinates, which essentially kills the interactivity
when in virtual cockpit mode. This won't be hard to fix; it's only
broken because I forgot the feature existed.
And one note about the implementation choice: to get away from the
inevitable near clip plane issue, the virtual cockpit renderer simply
disables the z buffer. This means that cockpits built using these
panels need to be z-sorted, which isn't too hard since they are static
geometry. It also means that no two "virtual panels" can ever be
allowed to interpenetrate. No biggie.
actually very powerful when combined with factor and offset -- for
example, on the C310 model the nose wheel can now retract completely
before the doors start closing.
subsystem to Flightgear. No more functionality is implemented
than at present (apart from an ATIS bug-fix - station wouldn't
change if the radio was switched directly from one station to
another) but it is much neater than the current hack and should be
easily extendable.
Some cruft is still probably left over in radiostack.[ch]xx such as
the bindings to the comm frequencies but I'll leave removing those
until I'm sure they're not needed there.
newauto.cxx. Basically everything is the same functionally except for a
changed in the initial altitude setting to 3000ft instead of meters (the panel
is in feet).
and scaling of control values to properties. Also added a time interpolation
feature that replaces the hacked-in "retract-time" feature for the gear in
a more general way (applicable to flaps, too!). Incompatibly breaks
the XML syntax; get new files!
individual aircraft to have different sounds (and cleaning up my code
a fair bit). The most important user-visible change is the renaming
of the /sim/sound property to /sim/sound/audible.
(other than "none") is "spin", which must be tied to a property giving
a value in RPM. This gets the DC-3 propellers turning. The next type
will be "rotation", which will allow the flaps, elevators, ailerons,
and rudders to move (and even gear, eventually). Later, I'll add
"shift" for sliding things around, and will figure something out for
blinking lights.
the XML file, including the path to the 3D file.
This change obsoletes the existing /sim/model/*-offset-deg and
/sim/model/*-offset-m properties in the main property tree, and
replaces them with /offsets/*-deg and /offsets/*-m in the model
property file. The /path property in the model XML file is relative
to the XML file's location rather than FG_ROOT.
