We don't use that info for anything, and it generates unnecessary diffs
every time we bump the minor version (and CI failures if we forget to
sync some files from opt-in modules (mono, text_server_fb).
(cherry picked from commit 81064cc239)
This makes it easier to spot syntax errors when editing the
class reference. The schema is referenced locally so validation
can still work offline.
Each class XML's schema conformance is also checked on GitHub Actions.
For the time being we don't support writing a description for those, preferring
having all details in the method's description.
Using self-closing tags saves half the lines, and prevents contributors from
thinking that they should write the argument or return documentation there.
(cherry picked from commit 7adf4cc9b5)
As a bonus, to have consistency between use Beziers and create insert tracks, use Beziers also gets a default via editor settings that is used when the confirmation dialog is disabled, instead of just falling back to creating non-Bezier tracks.
Many newcomers are confused about which one to choose for animating
properties. This should help clarify the situation with regards
to AnimationPlayer versus Tween.
(cherry picked from commit 810b1341ce)
We already removed it from the online docs with #35132.
Currently it can only be "Built-In Types" (Variant types) or "Core"
(everything else), which is of limited use.
We might also want to consider dropping it from `ClassDB` altogether
in Godot 4.0.
- Document a few more properties and methods
- Add more information to many classes
- Fix lots of typos and gramar mistakes
- Use [code] tags for parameters consistently
- Use [b] and [i] tags consistently
- Put "Warning:" and "Note:" on their own line to be more visible,
and make them always bold
- Tweak formatting in code examples to be more readable
- Use double quotes consistently
- Add more links to third-party technologies
Elaborate the difference between AnimationPlayer::advance and
AnimationPlayer::seek, specifically how intermediary events are handled for
each.
From the docs it is unclear that AnimationPlayer::advance is more of a
'fast-forward', playing each event (including function calls) between the two
points.
playing speed of the animation being played.
As stated in #16550, there is no way to get the playing speed of an
animation. The `playback_speed` property is for the whole AnimationPlayer
node, and the argument passed to `play` method is another scale applied
in top of the AnimationPlayer properties.
Thus, the actual playing speed is AnimationPlayer.speed_scale *
AnimationPlayer.playback.current.speed_scale. If it is not playing, the
method returns 0.
Rémi Verschelde
Haoyu Qiu
kobewi
Hugo Locurcio
Pedro J. Estébanez
Paul Joannon
Aaron Franke
20kdc
Michael Alexsander Silva Dias
Ignacio Etcheverry
Michael Pobega
Luiz
Ben Rog-Wilhelm
Saracen
robojumper
robfram