- rename prop-key-handler.nas to prop_key_handler.nas (the hyphens were
intentional, exactly to *make* using it as namespace less inviting,
but times change ...)
- add property browser binding to the '/'-key for when the property key handler
is turned off (/sim/input/property-key-handler=0). If it's on, use /: or
/<property>: to open the browser.
- run keyboard event listener only when property key handler is active
I hope that the '/' key can keep this binding even after a keyboard review.
The '/' is just the most natural key for dealing with properties, and it's
far less prominent on non-US-keyboards (e.g. Shift-7 on German keyboards),
so it's not really very well suited for important aircraft functions, anyway.
But I don't insist. :-)
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.
- allow turning on/off extra widgets for developers (HUD dialog: colors,
rendering dialog: visualization of shadow edges), and to turn on/off new
- property key handler ('/'-key)
Both features are off by default, and their state is saved to autosave.xml.
the property attribute string, as in:
(NONE, L1, #8345)
... for a node of type "NONE", with one listener attached, and 8345 instances
of the shared pointer around.
- use more "var" keywords and named args
- popupTip(): add optional third hash argument that is merged with the
dialog properies hash. This can be used to select different font or
dialog colors, etc.
/sim/current-view/dynamic-view. There are additionally <dynamic-view>
settings per view, but those only enable it for that view if it's
globally turned on.
it and the description doesn't match any more. :-}
Number of frames makes more sense than seconds (default = 1):
debug.proptrace([<property> [, <number_of_frames>]]);
writes (not directly written tied ones), all node additions and removal.
Frames are separated with a line. Turn off ANSI coloring if you want to
pipe the results into a file: --prop:sim/startup/terminal-ansi-colors=0
a regular function argument for that. Note the "n" in this example:
setlistener("/sim/current-view/view-number", func(n) {
setprop("/sim/hud/visibility", !n.getValue());
}, 1);
code that is called from outside. It will be removed from the global namespace
once it has done its job. For now it only selects a proper runway for wind
directions reported by METAR, but only, of course, if an airport was chosen,
but no runway and no heading, and if the aircraft is actually on ground.
from its property tree. The node remains accessible as long as references
to it are kept. Example:
var cow_chain = func {
var cow = geo.put_model("Models/Fauna/cow.ac", geo.aircraft_position());
settimer(func { cow.remove() }, 10);
settimer(cow_chain, 2);
}
cow_chain();
the $FG_ROOT/Nasal/*.nas ones are done. This allows to use props.Node etc.
immediately, without requirement for settimer(func{}, 0) constructions.
Rationale:
- clean separation of local additions (and hacks :-) from standard files
- users might not have write permission to $FG_ROOT/Nasal/ or shouldn't
have to su to root for writing Nasal code
- Page up/down changes the selected throttles one step up/down, i.e.
if the original throttle settings were x steps apart they remain
steps apart (unless the boundary is reached).
- Mouse + MMB drag changes the selected throttles by the delta amount
(length of drag).
- The throttleAxis() wrapper for joysticks sets the selected
throttles to correspond to the joystick's axis position. I.e. all
selected engines will get the same throttle setting. Since most
joystick throttles are positional devices I think this behaviour
is more logical than using a relative adjustment in this case. """
mf: slightly modified, added var etc. (more such changes in controls.nas
to come)
- move "fire starter" from SPACE-key to s-key
- move "open property browser" from Shift-SPACE to Shift-Enter (Shift-Return)
- implement PTT on SPACE/Shift-SPACE (with the other six SPACE/modifier
combinations unused, apart from a popup)
- add controls.ptt(v) wrapper function (v can be 1 or 2 for on, and 0 for off)
Easter-Egg:
- pressing the t-key for at least one second resets the warp delta.
This is an experimental feature that most people won't notice. It's meant
for investigating if suchlike "unorthodox" key use is acceptable. While
modifier-keys are the norm on computer keyboards, modifier-times aren't,
although we are used to them from other devices, such as alarm clocks etc.)
May later get removed without warning.
algorithm (needed for the file selector and useful for other purposes, like
assembling lists of livery or screenshot files etc.)
- io.nas: move fixpath to string.nas (it's not only useful for file paths
but can also be used for property paths)
- screen.nas: move trim to string.nas (used by screen.nas and nasal-console.xml)
- gui.nas: add pattern matching to FileSelctor
- ufo.nas: use patterm matching (only *.ac and *.xml files shall be listed)
with Coord.lat() and Coord.lon(), and because this is the preferable unit
in script space)
- add put_model(<path>, <coord> [, <hdg> [, <pitch> [, <roll>]]]) variant,
which takes a Coord instead of <lon>/<lat>/<alt>). Here's some inspiration:
setlistener("/sim/signals/click", func {
geo.put_model("Models/Fauna/cow.ac", geo.click_position(), 360 * rand());
});
dialog's <name> entry)
- FileSelctor: new class derived from Dialog. It clones the file-select
dialog and reports chosen files/dirs via callback function.
a side effect of the stack loop already
- replace all backslashes by slashes, to avoid security problems on UNIX
(if support for them is desirable on MS Windows, then we'd need an OS
property)
all children, vectors for multiply used names, further hashes for subtrees
etc. Meant for quickly pulling in config branches where (almost) all values
are needed.
- usage of "var" keyword and named parameters in other (but not all) funcs
- add put_model() function to place models at given lon/lat. If
elevation is nil, then it will be put on the surface. The path is
relative to $FG_ROOT.
- let geo.click_position() and geo.aircraft_position() return copies
of the Coord class, not just a reference
view.nas: adaptation for geo.nas change; minor changes
debug.color(bool) turns terminal colors on/off
debug.tree(property="", mode=1); dumps property tree in flat
mode (0) or space indented mode (1).
Flat tree mode is similar to props.debug(), but colored, and it outputs
all attribute flags and the number of attached listeners.
those from traffic manager and AI, so that it will later be possible to
load the data into the UFO Scenery Object Editor, to visualize and edit
parking positions, taxiing routes etc. The parser also allows to suck
arbitrary (simple) XML data files into fgfs from Nasal context.
In the long run the non-standard XML files in fgfs shall, of course, be
converted to standard format, in which no data may be stored in attributes.
- rename <interval> to <wait>
- add <step-time> and <exit-time> on the <tutorial> level for default
step iteration and exit time
- let <init>, <step>, <error>, <end>, <abort> share handler for
<marker>, <set>, <view>, <nasal>
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.
