development. The file must be an XML file with Nasal between a
header/footer. It's a good idea to give it a *.nas extension, so
that editors choose the Nasal syntax coloring.
<PropertyList><script><![CDATA[
... here goes the Nasal code ...
]]></script></PropertyList>
$FG_ROOT/gui/dialogs/tutorial.xml. It combines the former selection
and description dialogs, which makes browsing much more pleasant.
No more switching back and forth between the two old dialogs. Also,
the <list> box can handle a bigger number of tutorials than the
<combo> box could.
- remove comments from the top of tutorial.nas. The documentation is
now $FG_ROOT/Docs/README.tutorials
- add a <delay> property that can be used at top level (for the default),
and in <init> and <step> (Time in seconds in which the main loop should
run again.)
- fix initialization bug
the "voice" part. It's no longer possible to display the three letters {|}
in screen message at the moment, but they aren't overly useful. We may want
to support escaping in the future, if necessary.
Negative values show that you are actually moving away. To avoid division
by zero, a small value is always added to speed. So, if you aren't moving
at all, you still get a non-infinity, but huge ETA.
- <set> pair: allow to set <property> from <value> or second <property>
- support <set> pairs in <end>, too. This can be used to restore values.
- add optional <view> to <init>/<step>/<exit>/<end>. This is meant for
cockpit tutorials. See the Lightning's startup tutorial for an example.
- add view manager for saving/restoring and moving/interpolating view
axes & fov to absolute values. This is used for cockpit tutorials in
$FG_ROOT/Nasal/tutorial.nas
- check a step's errors in random order (otherwise a retarded instructor
bitches minutes about the climb angle, and only then notices that the
heading is totally wrong ;-) ... mabye simple scheduling would be better
- document embedded <nasal>
- start of <view> support
entries /sim/tutorial/targets/target[n]/{distance-m,direction-deg} are
provided and kept up-to-date. A direction angle of 0 means that the target
is straight ahead, 90 means it's to the right (3 o'clock) 179 means the
target is right behind, etc.
- everywhere where <message> and/or <audio> is supported, there can be more
of those entries, in which case one is randomly chosen. This is to make
the instructions less monotone:
<message>You are too fast. Fly at 100 knots.</message>
<message>Not so fast. 100 knots are more than enough.</message>
<message>Slower! Idiot!</message> ;-)
- simple geo coordinates class: geo.Coord with methods to set/get single
components, to apply distance/course and the get distance/course to other
coords
- functions that return click and aircraft position as geo.Coord
- function that returns tile_path for given lon/lat
- function that returns normalized angle (0 <= angle < 360)
Help->Nasal-Console opens the adjustment dialog
- reset Nasal namespace for emebedded Nasal for every tutorial
- rename <voice> to <audio> (in the hope that this won't be mixed up
with Festival voice synthesis; should we call it <audio-sample>?)
- rename <instruction> to <message> for consistency reasons, so there
are now <step><message>s, <error><message>s, and <end><message>s
- add <marker> support (blinking magenta circle to point to switches etc.)
- use "real" conditions instead of tutorial-only ones
- list of <error> with <message> and <condition> children, instead
of one <error> group with <check> items (necessary because of <condition>)
- only one <exit> (use <condition><and>... to define a set
- rename properties <prop><val><msg> to <property><value><message>
(consistency with other systems)
- <end><message>/<voice> instead of <endtext> and <endtext-voice> etc.
- add <nasal> support everywhere, with separate namespace and predefined
tutorial functions in it (currently only say(), next(), previous())
- make <timeofday> property actually work
TODO:
- more cleanup/re-organization
- add optional <view> group, to direct user view to switches (for startup
tutorials etc.)
2-space indentation changed to tabs (with Stuarts permission), and braces
to K&R style (rationale on request :-)
by debug.nas to turn on/off syntax coloring for dumped data (which
is desirable as compound data types can fill several screens with
rather hard to read data). Unfortunately, it can't be reliably deduced
from the OS whether ANSI colors are available or not.
- move "multiplayer chat" properties to where they belong
- use extra function for resuming normal mode after lookat: dynamic_view.resume()
- add fov (field-of-view) to interface: me.fov_offset
- remove register_headshake and me.headshake; this can still be done via
normal register(). If only headshaking is to be added, while keeping default
plane view, do this:
dynamic_view.register(func {
default_plane();
me.x_offset = ...
me.y_offset = ...
me.z_offset = ...
});
- initialize /sim/time/delta-realtime-sec, so that the lowpass filter doesn't
complain if it's starter eraly (of course the results won't be correct
until the delta is real)
aircraft can plug a custom function. This function can access all internal
variables of the ViewManager class. It can set me.{x,y,z}_offset, and also
add offsets to me.{heading,pitch,roll}_offset. Example:
dynamic_view.register_headshake(func {
me.x_offset = rand() * 0.02; # Parkinson effect
});
The advantage of this implementation is that it doesn't break MMB drag
functionality, and that is can be frozen by mouse movements.
or of given frame
- add debug.string(<variable>). This returns the variable dump as
string.
- add var to module function variables to avoid collisions with module names
Remember: dynamic_view.lookat(heading, pitch, roll) moves view
smoothly to this direction, while dynamic_view.lookat() moves it back.
This can be used for quick view changes to the panel etc. It's currently
only used in the bo105 (flaps-up binding).
This isn't only more logical, it's also how SGPropertyNode::getBoolValue()
acts. The fix has potential to break code, but so far I haven't seen any
problems. I added a debug message to my copy and will for a while check
all cases that I run into. To check yourself, just add one line:
getBoolValue : func {
val = me.getValue();
+ if(val == nil) { debug.dump(me) }
if(me.getType() == "STRING" and val == "false") { 0 }
else { val != nil and val != 0 }
}
This will output a debug message to the terminal for each case where
formerly "true" was returned, and now "false" is.
- use Nasal features that were introduced after this code was first written:
* var for local variables (and to make clear when a variable is first used)
* += operator
* listeners to import seldom changing variables and to avoid waiting for
the FDM in a loop
This new code started as empty file where I added my stuff and then copied
parts from the old code, piece by piece. This is why the coding & indentation
style has changed. Functionally the code should basically be equivalent.
can also write
<sim>
<aircraft-data>
<path>/sim/author</path>
<path>/sim/description</path>
<path>/sim/rtatus</path>
</aircraft-data>
</sim>
in a *-set.xml file instead of using Nasal (aircraft.data.add("/sim/author", ...)
- s/timeN/node/ to match the pattern described in the head comment
- make listener on-shot
- make 0 a valid saving interval, and 'nil' or no arg stop the loop
(this is for consistency with settimer() or aircraft.timer() intervals
- smaller fixes, cleanup
Examples:
var tied = foo.getAttribute("TIED");
foo.setAttribute("USERARCHIVE", 1);
Both methods accept attribute strings "READ", "WRITE", "ARCHIVE",
"TRACE_READ", "TRACE_WRITE", and "USERARCHIVE". getAttribute() does
additionally accept "TIED" (although this isn't an SGPropertyNode::Attribute).
Attribute "REMOVED" is not supported.
registered with dynamic_view.register() and is called in the main loop,
replacing the default plane/helicopter function. This has access to
all class functions/members and sets me.heading_offset, me.pitch_offset,
and me.roll_offset, which are then used as new view offsets.
The function can also do other things, such as call the lookat() method
to temporarily set heading and pitch. See the bo105 for an example.
While further minor changes are to be expected, the configuration method
seems to be the way to go.
- dynamic_view.nas: use aircraft.lowpass() class
This makes the dynamic view independent of the frame rate. Currently,
each filter instance reads out dt on its own, which is a bit inefficient.
I'll change that to just one read for all instances later (when Nasal
implemented predictable module loading order. :-)
- fix sliders: revisions 1.43/1.44 had introduced a mandatory <min-lb>;
if that was missing, a slider without handle was generated, and a click
on the slider lead to a crash.
-> check for both <min-lb> and <max-lb> and set default values
0, respectively 100
var min = w.getNode("min-lb", 1).getValue();
var max = w.getNode("max-lb", 1).getValue();
slider.set("min", min != nil ? min : 0);
slider.set("max", max != nil ? max : 100);
preferences.xml gui/menubar.xml gui/dialogs/rendering.xml
Added Files:
Nasal/multiplayer.nas gui/dialogs/chat.xml
gui/dialogs/chat_full.xml:
the data part of Stuarts multiplayer/chat patch
tank indices, so that changing drop tanks automatically modifies the
corresponding FDM tank capacity (and load, if it is too high).
Add the new tank stuff to the harrier config, along with a few new
items (e.g. AMRAAMs on the outboard pylons) that aren't in the 3D
model yet, but correspond to actual usage.
An IRC discussion about shavlir's (really nice) harrier model showed
that it had its own version of something like the Fuel & Weight
dialog, developed because the existing subsystem only supported
sliders and not "combo box" style selection for specific external
stores. That seemed sub-optimal, so I spent a few hours extending the
F&W dialog to do this and forward-ported the harrier to use it.
Check the harrier-set.xml file for an example. Basically, the weight
dialog reads a list of options for each weight listed under
/sim/weight[n] and manages a "selected" proprty telling us which one
is in use. The FDM code can then read out the weight-lb property as
before, and the model animations can use the selected option to
predicate drawing the appropriate 3D content. It seems to work pretty
well.
Unfortunately, this is quite jittery on some aircraft, so it uses a slower
lowpass filter. I'd like to fix that, but don't even know what causes it.
Considering /sim/time/delta-realtime-sec didn't help. :-/
entry "View->Toggle Dynamic Cockpit View" entry; state saved to autosave.xml;
there are no configuration parameters yet, but the default values work for
most aircraft; exceptions: ground steering effect of jsbsim aircraft is
jittery; yawing effect on big aircraft is too abrupt. This needs to be
configurable.
Suggestions for improvements are welcome if they are bundled with a
working diff that actually proves the claimed advantages. :-)
<close> block, remove autopilot helper file autopilot.nas and (re)implement
its functionality in autopilot.xml
- make AP dialog "bidirectional" and "live": all input fields are <live>
(i.e. they are updated as the autopilot settings are changed, for example
by panel actions or property browser changes)
- dialog input is only forwarded to the AP; no direct checkbox/radiobutton
handling through widget operation, instead:
- changes to the AP properties operate checkboxes/radiobuttons
This makes the AP dialog always reflect the AP state. If the AP refuses
one setting and sets it back to something else, then the dialog will
immediately react and show the actual setting.
mf:
- some minor modifications to Stuart's version :-)
- select all engines per default. This may seem less realistic (who starts
all engines on the b29 at once?), but it'll prevent oodles of bug reports.
And those who want it realistic shouldn't rely on engine 1 being selected
by default, anyway, but rather actively select every single engine.
Also: this new behavior is in line with the original intentions (see cvs
log to preferences.xml -r1.51)
- always disable tutorial-stop; enable tutorial-start if tutorial available
- don't call the tutorial selector "Wizard 1/2". There is only one tutorial
selector, the next dialog is already part of the tutorial. Also, the dialogs
don't guide you through multi-dialog setup, which is what "wizards" normally
stand for.
- use tutorial name as dialog title
- set button shortcuts (default == return, esc)
- make esc go back to select dialog
- beautify sliders & some other tweaks
