https://en.wikipedia.org/wiki/Noto_fonts
Noto is a font family comprising over 100 individual fonts, which are together designed to cover all the scripts encoded in the Unicode standard.
There are 3 relevant render bins for aircraft models:
- 0: default
- 10: depth sorted, automatically selected for transparent objects.
- 111: depth sorted, explicitly set by some transparent effects (hud, glass)
The model-default effect does not set <render-bin> on purpose, to allow
automatic selection of bin 0 or 10. So my second patch which added <render-bin>
to model-default is wrong.
It is only model-transparent which should explicitly set bin 111
to interact well with hud/glass effects.
Change to calculate the frame rate ourselves because /sim/frame-rate doesn't take into account freeze and has a transient ridiculous value after a pause. Instead we calculate the average rate over a period and then LP filter this.
This also removes the annoying frame rate update messages
Cofiguration now comes from /sim/emexec
* /sim/emexec/monitor-period is the period to reset the average; the LP filter isn't reset.
* /sim/emexec/max-rate-hz is the upper limit on the emexec update rate. defaults to 50 and a model can override this. It's probably not a user setting
output of
* current emexec rate into /sim/emexec/rate-hz
* smoothed / LP filtered frame rate into /sim/emexec/frame-rate
- ensure createItem returns the item
- add an accessor for text()
- don't do lazy view creation for now
- skip aboutToShow until item iteration works for me
This concerns a single character inside a comment, so won't change the
behavior of the Nasal code in any way. Beside using the favored encoding
in FlightGear, this little change allows scripts/python/nasal_api_doc.py
(from the FlightGear repository) to work again without having to teach
it to ignore encoding errors nor to play at guessing the encoding of the
files it reads.
Since commit e41c0f099b, the Tooltip class has performed string
interpolation (i.e., sprintf()-style formatting) regardless of whether a
<property> was specified for the tooltip. This broke the API of
gui.popupTip(): all '%' characters in the message had to be doubled to
work as before. This commit restores the normal behavior of
gui.popupTip() where '%' characters aren't interpreted in any special
way.
