so n.initNode("whatever", 1 "BOOL", 1); will make node n a BOOL even
if it was "DOUBLE" before. Default: 0. An existing value will be retained,
though.
(/sim/rendering/precipitation-gui-enabled) *and* if the aircraft wants it
(/sim/rendering/precipitation-aircraft-enabled). Some aircraft model rain
on the windshield and want to turn rain off for interior views.
earlier available. (The settimer/1 was a workaround for another
problem that should be fixed by now.)
globals.nas: load $FG_HOME/Nasal/ files as first settimer(0) function,
so that it always comes after all nasal-dir-initialized callbacks
This should fix the glide_slope_tunnel/popupTip bug and makes the
startup order clearer and cleaner.
props.nas: replace some "arg[*]" by named args
aircraft.nas: load aircraft data only if the file exists (to avoid warning)
debug.nas: no space before colon & fixed comment & cosmetics
- fuel.nas: use props.initNode()
- debug.nas: fix comment
- globals.nas: load_nasal(): check extension and set module arg
- io.nas: update log message (the rules are no longer for io.open() only)
no way yet to safely detect absolute paths, so this would break on MS Windows.
This will only mean that relative paths will always fail, as they don't
match any pattern. These are all absolute.
If the property has a valid value already, then the given value is ignored.
var x = props.initNode("/foo", 10);
var y = props.initNode("/bar", 1, "BOOL");
debug.dump([a, b]) for that, but debug.dump(a, b) is more obvious)
- change output colors: variable names are no longer bold, all property
attributes are now blue, not just the property type)
- drop redundant braces & other cosmetics
and path strings into a list of props.Nodes. It also digests lists of
properties, or lists of lists of properties etc., thus allowing things
like props.nodeList(arg), props.nodeList(n.getChildren("foo")). This is
meant for functions like aircraft.data.add() or screen.display.add().
- remove some redundant braces
- fix comment
- don't use screen.window, but let it do its own dialog handling. Thereby
- make it faster (update every frame by default)
- prevent collisions with the menu
- allow to move the dialog away (only the left edge is draggable!)
- try color white (better color suggestions welcome :-)
- 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.
livery_update class and add an optional third argument to its constructor:
a callback function that's called whenever the class noticed a livery
change
- Update redout level every frame
- Replace reading of properties every iteration with listeners
- move -onset and -complete properties into a parameters subtree
are set in controls.nas since ages)
controls.nas: avoid repeated querying of /sim/input/selected/engine[*]
properties; this isn't supposed to change at runtime and is a rather
costly process, especially in axis handlers
- 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.
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
functions when used in $FG_ROOT/Nasal/*.nas, because it
depends on props.nas being available; no restrictions in
aircraft files, where it will proof most useful
gui.nas: replace inefficient FPS display polling loop with listener
callback
- gui.nas: use 4-space indents like the rest of the file; waste slightly less
cycles: checking for the property shouldn't be done in a loop at
all, it only serves as a temporary solution
to pop themselves down while the simulator is paused.
The problem was with the "real time" queue in the event manager,
causing the third argument of Nasal's settimer() (a flag for "sim
time") to be ignored. Inverts the default sense of the argument, as
there are lots of uses of settimer() in the current code, almost none
of which want to use real time.
Note this fix introduces a header file incompatibility in SimGear --
be sure to update.
gear movement. gearToggle() was sending either a 0 (not handled) or a 1.
Change gearToggle() so it sends either -1 and 1 so gearToggle() will work
again.
- to support "old-style" gear/flap control (operation as long as button
pressed/lever pushed -> b29/hurricane), let bindings not only report
up/down, but up (-1), stop (0), down (1).
- let controls.flapsDown() ignore "stop" so as to remain compatible with
prior behavior
- adapt all joysticks/aircraft (sigh)
- some minor cosmetics in joystick configs, such as indentation fixes
Implement simple help system with global and aircraft specific dialogs:
The gui.nas changes have been discussed with Andy. All ac have a help dialog,
but some are empty. (This wouldn't have been necessary, as the system falls
back to the "Common Aircraft Keys" if an aircraft has no help defined, but an
empty dialog is less confusing and encourages to be filled with interesting
information. :-) I scanned all aircraft files for interesting performance
data and added some to the dialogs (stall speed, etc.) The Concorde and the
p51d have (over?)complete dialogs and can serve as examples. The format is
documented in $FG_ROOT/Nasa/gui.nas.
There is also a couple of other, minor fixes.
The following files have ugly MSDOS line endings:
$FG_ROOT/Aircraft/Hunter/hunter{-2tanks,}-set.xml
$FG_ROOT/Aircraft/A380/A380-set.xml
The Concorde-jsbsim.nas file is a useless copy of the real */nas file, which is
in Nasal/. I'was debugging the Concorde and wondered why changes to this file
had no effect ...
(Fixed Concorde in the help-ac.diff patch: don't use "interpol" keyword as
variable.)
- lights are by default off (what was I thinking?!?)
- setters return "me" reference by default, for easier code obfuscation:
foo = aircraft.light.new("/foo").prop().switch(1); :-)
- a few mebmers renamed; light.set() -> light.switch(); nodes are named *N
to avoid collisions and to show relations (switch() <-> switchN)
- yet more (too much?) documentation
- light class added (for lights and other pulsing/blinking objects)
- fixed and improved documentation
- all property args may be path strings or nodes
- existing nodes aren't overwritten any more
- better naming of class vars (for outside access)
Tested with the bo105 (which I fully ported to use aircraft.nas) and
the fokker70 (which are the only aircraft using the new classes :-)
Re-organisation: <diffuse>, <ambient>, <emission>, <specular> are
now groups with members <red>, <green>, <blue>, <factor>, <offset>,
and their <*-prop> forms. Additionally, there's an option <property-base>
that can be used to set a path that is prepended to all <*-prop> paths.
It defaults to an empty string. Rationale: see model-howto.html.
Changes:
o new skids (yet again)
o sun shield for the panel
o beautified exhausts
o new door handling:
"d" ... toggle selected door (default: pilot door)
"D" ... select next door (indicated with popup)
"Ctrl-d" ... remove selected door if opened (all bo105 doors can easily
get removed in RL; it is even flown without doors!)
o dropped shadow boxes (once necessary workaround for the disappearing
shadow problem, and the reason why the bo105 was so tiny in fgrun)
o automatically selects the emblem of the national Red Cross/Red Crescent
society on startup
o 5 variants, that can be switched at runtime, with different emblems,
colors(!), and extra equipment:
"c" ... switch to next variant
"C" ... pop-up material dialog, as a demonstration of the new
"material" animation, well ... and for entertainment
purposes :-)
The bo105 was and is a testbed for the "material" animation. It uses one to
change a texture at runtime. This has the advantage, that only the currently
selected texture uses up memory (unlike the textranslate method), and it
saves a lot of disk space because it doesn't duplicate all textures (unlike
the current <texture-path> method. You can change the texture in the browser:
http://localhost:5501/sim/model/bo105/material/emblem/texture
(choose one of: emblems/{red-cross,red-crescent-[lr],star-of-life}.rgb
(the built-in property browser doesn't grok it, because I used quite long
path names. Needs to be fixed in the GUI.)
I suggest to add the material.nas file to the global Nasal/ dir, not only
because the bo105 update expects it. The Nasal module creates a dialog for
material editing, which is quite useful for development purposes, for gaining
better understanding of the OpenGL color properties, and finally: it's fun.
http://members.aon.at/mfranz/material.jpg [45 kB]
The dialog needs to be initialized with a property dir where material
redirects are placed. It isn't available from the menu, but may be useful
for other aircraft. Also, it's quite small and doesn't get in the way.
If people want it removed, I can still move its contents into bo105.nas.
The bo keyboard binding says:
material.showDialog("/sim/model/bo105/material/fuselage/", "Bo105");
This is documented on top of the *.nas file.
Here are some updates to the KAP140 autopilot in the default c172. It now uses
ailerons and elevator instead of aileron-trim and elevator-trim. I've started
to "upgrade" it to the "two axis altitude preselect" version. Vertical speed
select rounds to nearest 100 fpm.
I've also modified the c172 electrical configuration to turn on the gps
instrument.
Perhaps the most important change is that the nasal script for the KAP140 has
moved from data/Nasal to the c172p aircraft subdir. So it is important that
you delete data/Nasal/kap140.nas. Having the kap140.nas script as a global
script was not a good solution. Now it is aircraft specific, and thus
included in the c172p-set.xml file. Ideally I would like it to be instrument
specific, so that it would be included whenever the KAP140*.xml instruments
where included on the panel.
typo; the SimGear "pass subproperty as first argument" shortcut
doesn't work in Nasal. This checkin is blind, but should have a high
probability of correctness.
I'd like to suggest that the spoiler settings are set in the same way as the
flaps are now done i.e. via Nasal, so that specific spoiler settings can also
be defined in the aircraft set file.
It was only when I was about to change the keyboard bindings for the slats
control that I remembered that there wasn't already a mapping for them in
keyboard.xml. I've _not_ added a mapping for slats as this is a bit of a hot
topic atm but as I had already added a Nasal func for the slats in
controls.nas I've left that in there. It's a trivial bit of code but I don't
know if leaving it in there is a good idea as it's code that shouldn't ever
be called until there's a corresponding keyboard mapping.
x/y/width/height values went into the calculation for the next popup,
and things got iteratively worse due to padding issues). But the
good news is that this whole subsystem is vastly simpler when
implemented with the new interface.
"engines die when any tank is empty" behavior. Otherwise, just
deselect the empty tank. This matches the "both" behavior many
lightplane fuel selectors have.
Here is the KAP140 Two Axis Autopilot update.
I think it's fairly complete now, all the modes are working. I tested the
localizer and glideslope hold and it was pretty stable all the way down to
the middle marker.
In the pilot guide for backcourse hold (REV) mode it says to reset the heading
bug to the _front course_. I haven't figured out how to implement this so for
the time beeing one should reset the heading bug to the _backcourse_. Apart
from this the panel should operate identical to the way the pilot guide
describes.
Here is the KAP140 Two Axis Autopilot.
Aircraft/Instruments/KAP140TwoAxis.xml
Is of course the instrument config file.
Aircraft/Instruments/Textures/KAP140.rgb
The texture.
Nasal/kap140.nas
Most of the work is done here. Without Nasal I don't see how I could implement
the NAV-ARM modes and the flashing annunciators.
Aircraft/c172p/Systems/KAP140.xml
The autopilot PID controllers configuration file. Maybe this file should be in
a more accessible directory and not hidden deep inside c172p!?
I've also attached the changes to the default C172 to include this autopilot
in the 3d-cockpit panel and the 2d vfr panel. Or at least I hope that I've
managed to include all that is needed.
tanks created by the C++ code look empty, and were causing the fuel
code to detect out of fuel conditions. Since there is no way to tell
a "FDM" tank from a "C++" tank, I just filter them by capacity. Very
ugly hack, we need to fix the code to report only the tanks created
by the aircraft/FDM configuration.
/sim/input/selected/engine[n] properties. Also, new properties get
empty string values (which are boolean true in Nasal, maybe that
should be changed?), so test for numeric truth.
Move the "tip popup" code from view.nas to a new gui.nas module, and
make it generically useful.
Wire up flap steppings for the 747 as an example of per-aircraft
flaps.
Realtime-based property slewing, to eliminate dependence of trim and
view direction rates on frame rate.
New Node.setValues() method which sets whole property trees from Nasal
data.
A view.nas module, which takes over handling of the X/x zoom keys. It
clamps the FOV to a dynamically calculated maximum corresponding to
typical human visual accuity, and pops up a pretty dialog informing
you of the new FOV.
