We remember the multiplayer aircraft so that when switching between views,
multiplayer views (currently Helicopter, Model, Tower and Tower AGL) show the
same aircraft.
Nasal/view.nas: use /orientation/true-heading-deg in Model view and Tower AGL
view. This avoids problem when looking at multiplayer aircraft because there is
no /ai/models/multiplayer[]/orientation/heading-deg
Nasal/view.nas: improved handling of sim/current-view/{x,y,z}-offset-m. Changed
resetViewPos() to set these all to zero, because view's offsets are now
kept separate. Also removed setting of /sim/current-view/z-offset-m to
chase-distance - this is the wrong place now that views define the offset
explicitly.
Also added Tower View AGL support.
The reason it didn't work for me is that
/sim/rendering/camera-group/camera/viewport/ does not seem to contain
the actual dimensions of the view window... which is odd. Instead I'll
use /sim/startup/[xy]size (and make it into a method so I don't have to
change 3 lines next time :). Now that it works (again), it looks so much
better. Thanks to Alexis Bory for the original idea.
* make into singleton class
* make sure FOV changes take place *immediately* when required
* current FOV is scaled with changes, though being preserved: resizing
window and going back ends up with the same FOV
"/sim/signals/fdm-initialized" triggers _every_ time the FDM is reset,
so for every sim reset/relocate.
We need to uninstall the listeners after its first execution, or guard
certain parts of the initialization, to avoid starting multiple
"timer/update loops", or installing multiple property listeners.
Repeating "sim reset" often enough would eventually completely block/
overload the system.
When user switched to a different view mode (e.g. chase/helicopter/tower
view) before or during a tutorial, everything went wrong...
Need to control (save/restore/switch) the view number (view mode) during
tutorials. Also adds an option to explicitly change view mode during
a tutorial, i.e. tutorials can switch to tower view, chase view, ... now.
aircraft system, rather than "core" data.
Fix a long standing annoyance (for me anyway) when the fly-by-view is first
instantiated, it never put a point forward very far so the first transtion
came very quickly and abruptly. Improve the forward prediction based on
ground speed and time when the view is reset (or switched to.) I like this
a lot better personally.
- new parameter naming (left/right instead of min/max; signs are ignored)
- fix wrap-around skips
- use regular constructor so as not to confuse people ;-)
If a <view> contains a <limits> block, then a view handler gets attached to
it, which limits head turns to a given range, whereby headings beyond a given
threshold cause an additional sideways movement. This is turned off by default
for now.
These are then skipped with view.stepView(n), unless the second, optional
argument is set to 1: view.stepView(n, 1);
Whether a view is enabled or not, is saved in $FG_ROOT/.fgfs/autosave.xml
(system views) or $FG_ROOT/.fgfs/aircraft-data/<aircraft>.xml
I tried it the nice way, but it didn't work. Why is it important to
reserve indices for fgfs? Because someone has otherwise to go through
all aircraft in CVS and move aircraft specific views out of the way,
every time a system view gets added. Been there, done that.
