When using high physics FPS (which is a requirement to minimize input
lag and improve precision in simulation racing games), a higher value
prevents the game from slowing down at low rendering FPS.
This can be done via an Engine property for run-time changes,
or a project setting for initial changes.
This makes the setting easier to find, as research has found there are
numerous use cases to limiting FPS. This also improves documentation
related to the Engine property and project setting.
The project setting also works in projects exported in release mode,
so its location in the `debug/` section was misleading.
This quits the project when an animation is done playing in the
given AnimationPlayer, but only in Movie Maker mode.
When this happens, a message is printed with the absolute path of the
AnimationPlayer node that caused the engine to quit.
This can be used to create videos that stop at a specified time
without having to write any script.
A report is now also printed to the console when the video is done
recording (as long as the engine was exited properly).
This report is unfortunately not always visible in the editor's
Output panel, as it's printed too late.
A method was also added to get the path to the output file from the
scripting API.
* Ability to create script languages from GDExtension
* Some additions to gdnative_extension.h to make this happen
* Moved the GDExtension binder to core
This now allows creating scripting languages from GDExtension, with the same ease as if it was a module. It replaces the old PluginScript from Godot 3.x.
Warning: GodotCPP will need to be updated to support this (it may be a bit of work as ScriptInstance needs to be created over there again).
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.
The `Engine.set_editor_hint()` setter method is no longer exposed
to scripting, which makes the property effectively read-only from
an user perspective.
* Exposed functions in Engine to register and unregister singletons.
* Added the concept of user singletons, which can be removed (the system ones can't).
This makes it clearer that this property is only about physics FPS,
not rendering FPS.
The `physics_fps` project setting was also renamed to
`physics_ticks_per_second` for consistency.
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.
This pull request fixes an assortment of typos and improves conciseness in `Animation`, `Area2D`, `Array`, `ArrayMesh`, `Control`, `Directory`, `EditorPlugin`, `Engine`, and `OS`.
Physics FPS above 1000 cause the whole project to slow down
and are not very practical in the first place (since no CPU currently
available can keep up).
This can be used during unit test suite runs to hide error and warning
messages.
Care should be taken when using this feature, as it can hide important
information if used wrongly.
New contributors added to AUTHORS:
@hinlopen, @naithar, @rrcore, @SkyLucilfer, @TwistedTwigleg
Thanks to all contributors and donors for making Godot possible!
---
Also changes to relevant code that parses the DONORS.md to match
the new tiers.
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.
Addresses #30068
This is a prerequisite for allowing proper support for fixed timestep interpolation, exposing the interpolation fraction to the engine, modules and gdscript.
The interpolation fraction is the fraction through the current physics tick at the time of the current frame.
- 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
