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.
- Accelerate common path used to check the storage scope for a given path
- Update the logic for the `get_as_text()` method - previous logic loads the content of a text file one byte at a time
- RPC configurations are now dictionaries.
- Script.get_rpc_methods renamed to Script.get_rpc_config.
- Node.rpc[_id] and Callable.rpc now return an Error.
- Refactor MultiplayerAPI to allow extension.
- New MultiplayerAPI.rpc method with Array argument (for scripts).
- Move the default MultiplayerAPI implementation to a module.
On #43310, class reference was automatically updated from source,
causing xml documentation to disagree with parameter naming
description on Plane.intersects_segment().
Weirdly, it also changed the parameter for Plane.is_point_over()
from point to plane, when only the first has sense (and it is
defined on math.Plane as "const Vector3 &p_point"). Manual
mistake?
* Update begin/end to from/to on Plane.intersects_segment(...)
docs description to match source
* Update Plane bindings to use points instread of plane for
is_point_over(...)
* Change Plane.is_point_over(plane) to Plane.is_point_over(point)
AND its description on docs
Fixesgodotengine/godot-docs#5976
Implement built-in classes Vector4, Vector4i and Projection.
* Two versions of Vector4 (float and integer).
* A Projection class, which is a 4x4 matrix specialized in projection types.
These types have been requested for a long time, but given they were very corner case they were not added before.
Because in Godot 4, reimplementing parts of the rendering engine is now possible, access to these types (heavily used by the rendering code) becomes a necessity.
**Q**: Why Projection and not Matrix4?
**A**: Godot does not use Matrix2, Matrix3, Matrix4x3, etc. naming convention because, within the engine, these types always have a *purpose*. As such, Godot names them: Transform2D, Transform3D or Basis. In this case, this 4x4 matrix is _always_ used as a _Projection_, hence the naming.
This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks
that can be run on threads (and then waited for). It satisfies the following use cases:
* HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads.
* Thread spawning is slow in general, so reusing threads is faster anyway.
* This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks.
After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
This PR is a continuation of #50381 (which was implemented exactly a year ago!)
* Add a visual interface to select which classes should not be built into Godot (well, they are built if something else uses them, but if not used the optimizer will remove them out).
* Add a detection system to scan the project and figure out the actual classes used.
* Added the ability for SCons to load build profiles.
Obligatory Screen:
A simple test with a couple of nodes in the scene resulted in a 25% reduction for the final binary size
TODO:
* Script languages need to implement used class detection (left for another PR).
* Options to disable servers or server functionalities (like 2D or 3D physics, navigation, etc). Are missing, that should also greatly aid in reducing binary size.
* Options to disable some modules would be desired.
* More options to disable drivers (OpenGL, Vulkan, etc) would be desired.
In general this PR is a starting point for more contributors to improve and enhance this functionality.
Read/write ops for this implementation are done through the java layer via jni, and so for good performance, it's key to avoid numerous repeated small read/write ops due the jni overhead.
The alternative is to allocate a (conversatively-sized) large buffer to reduce the number of read/write ops over the jni boundary.
