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).
Adds a check to make_rst to look for matches
between the text inside of the [code][/code] tag
and known param identifiers.
Fixes most of what was revealed.
The editor will now use the project path i.e. the place where the root of
the repo is supposed to be according to the user. This project path is
also sent into the plugin and so out-of-directory asset folders can also be
maintained this way.
This has been superseded by GDExtension so this code is no longer useful
nor usable.
There's still some GDNative-related stuff in platform export code which
needs to be adapted for GDExtension (e.g. to include GDExtension libraries
in exports).
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.
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.
- Add some missing descriptions.
- Add links to tutorials for ARVR and AnimationTree.
- Style fixes.
- Engine changes:
* Make `AnimationNodeTransition.input_<number>` properties internal
so that they don't appear in the docs. They still appear in the
inspector based on the actual number of inputs requested.
* Drop unimplemented `CPUParticles.flatness`. It's only used for 3D
particles in `ParticlesMaterial`, and thus only relevant for
`CPUParticles3D`.
The VCS interface can be thought of like a proxy system, where any call
to the API is redirected to the actual implementation of the VCS API
which may be existing in the form of a GDNative plugin which is marked
as a singleton and is not marked reloadable. If the implementation
doesn't exist in the file system, it only returns the default responses which contain
mostly empty containers of the data type that every API call returns.
EditorVCSInterface is used like a Godot object with a script attached to it. The script
is the implementation of the API and the object is the interface to the
script, which returns default responses if the script doesn't exist or
if the script doesn't define a function that handles that particular API call.
The entire system has been implemented using Object::call() and its
ability to switch to the script instance to handle the API call if the
script exists. Look for VersionControlEditorPlugin::_initialize() for
the essential API setup.
