The main change is to caculate tangent directly from bezier curve, without going
through discretized polyline, avoiding pitfalls of discretization. A similar refacor
had been applied to Curve3D.
The test cases for Curve2D is updated, comparing floating point with is_equal_approxmiate()
instead of `==`, in order to avoid float precision problem.
The main change is to caculate tangent directly from bezier curve, without going
through discretized polyline, avoiding pitfalls of discretization.
Other changes are:
1. Add an bezier_derivative() method for Vector3, Vector2, and Math;
2. Add an tesselate_even_length() method to Curve3D, which tesselate bezier curve to even length segments adaptively;
3. Cache the tangent vectors in baked_tangent_vector_cache;
- Removed empty paragraphs in XML.
- Consistently use bold style for "Example:", on a new line.
- Fix usage of `[code]` when hyperlinks could be used (`[member]`, `[constant]`).
- Fix invalid usage of backticks for inline code in BBCode.
- Fix some American/British English spelling inconsistencies.
- Other minor fixes spotted along the way, including typo fixes with codespell.
- Don't specify `@GlobalScope` for `enum` and `constant`.
General:
- Replace most type names with strong references (such as "integer" to "[int]");
- Made the writing style closer to how the rest of the documentation is formatted.
- Use uppercase Inspector when referring to the Inspector dock.
- Describe missing MethodFlags, Variant.Type constants.
Key:
- Add " key." to the `KEY_0` to `KEY_9` constants;
- Reword some MouseButton constants;
- In a programming context, it's kind of odd hearing about the plural of "mouse".
Error:
- Reword OK constant to flow better, use `printerr()` over `print()`;
- Describe where `ERR_HELP` is used by the engine;
- Point to the Github Issues Page in ERR_BUG.
PropertyHint:
- Mention that PROPERTY_HINT_IMAGE_COMPRESS_LOSSY and PROPERTY_HINT_IMAGE_COMPRESS_LOSSLESS are unused;
- Mention that PROPERTY_HINT_PASSWORD allows a placeholder string.
- Describe PROPERTY_HINT_OBJECT_TOO_BIG, PROPERTY_HINT_MAX.
PropertyUsageFlags:
- Describe PROPERTY_USAGE_HIGH_END_GFX, PROPERTY_USAGE_ARRAY.
Generally:
- Made use of [param] more frequently;
- Link to other classes' documentation more often;
- Improve and add more examples;
- Ensure that multiple comments of an codeblock example are spaced out equally for better readability;
- Made the writing style closer to how the rest of the documentation is formatted;
- Ensure these are called "functions", not "methods".
- Fixed a few typos.
- Touched up a few cases of zero being written as "zero" or "0" where "0" or "0.0" would be more appropriate.
- Removed mentions of "(real)". In 3.x, this was associated with floats, because TYPE_FLOAT was called TYPE_REAL.
More specifically:
- Every type-safe version of a function (such as `ceili` has a consistent final note ("A type-safe version of [method ceil], returning a [int]").
- Added more details to `randomize`, `seed`.
- Corrected `floori()`'s description. It's not the same as `int()`. This was not correct behavior and has been fixed.
For `PROPERTY_HINT_ENUM` properties, enumerator names can be provided as
a comma separated list. There're a few properties that add leading
spaces to the names (e.g. `First, Second, Third`).
These spaces are included in the Inspector dropdown, which is
unexpected.
It's better to leave the surrounding spaces untouched because it could
be part of the resulting string value (the variable is a string enum).
And most other enum hints don't contain surrounding whitespaces.
This PR removes the spaces and documents this `PROPERTY_HINT_ENUM`
behavior.
Removes separate `Command` key (use `Meta` instead).
Adds an event flag to automatically remap `Command` <-> `Control` (cannot be set alongside `Control` or `Meta`).
"less" should be used for quantity, rather than "lesser".
Existing scripts that use `or_lesser` in `_get_property_list()`
will need to be updated to account for this change.
As announced in https://godotengine.org/article/godot-4-will-discontinue-visual-scripting,
Godot maintainers have agreed to discontinue the current implementation of
our VisualScript language.
The way it had been designed was not user-friendly enough and we did not
succeed in improving its usability to actually make it a good low-code
solution for users who need one.
So we prefer to remove it for Godot 4.0 and leave the door open for new,
innovative ideas around visual scripting, to be developed as plugins or
extensions now that Godot provides sufficient functionality for this
(notably via GDExtension and the godot-cpp C++ bindings).
The current module has been moved to a dedicated repository (with full Git
history extracted with `git filter-branch`):
https://github.com/godotengine/godot-visual-script
It can still be compiled as a C++ module (for now, but will likely require
work to be kept in sync with the engine repository), but our hope is that
contributors will port it to GDExtension (which is quite compatibile with
the existing C++ module code when using the godot-cpp C++ bindings).
- 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.
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.
For this to work safely (user not call queue_free or something in the expression), a const call mode was added to Object and Variant (and optionally Script).
This mode ensures only const functions can be called, making it safe to use from the editor.
Co-Authored-By: reduz <reduzio@gmail.com>
This PR implements:
* A new hint: PROPERTY_HINT_NODE_TYPE for variant type OBJECT, which can take specific node types as hint string.
* The editor will show it as a node path, but will set it as a pointer to a node from the current scene if you select a path.
* When scene is saved, the node path is saved, then restored as a pointer.
NOTE: This is a proof of concept and this approach will most likely not work. The reason if that, if the node referenced is deleted, then when trying to edit this the node will become invalid.
Potential workarounds: Since this uses the Variant API, it should obtain the pointer from the Variant object ID. Yet, this would either only really work in GDScript or it would need to be implemented with workarounds in every language.
Alternative ways to make this work: Nodes could export an additional property with a node path (like for which_node, it could be which_node_path).
Another alternative: Path editing could happen as a hidden metadata (ignoring the pointer).
* Allows running the game in "movie writer" mode.
* It ensures entirely stable framerate, so your run can be saved stable and with proper sound (which is impossible if your CPU/GPU can't sustain doing this in real-time).
* If disabling vsync, it can save movies faster than the game is run, but if you want to control the interaction it can get difficult.
* Implements a simple, default MJPEG writer.
This new features has two main use cases, which have high demand:
* Saving game videos in high quality and ensuring the frame rate is *completely* stable, always.
* Using Godot as a tool to make movies and animations (which is ideal if you want interaction, or creating them procedurally. No other software is as good for this).
**Note**: This feature **IS NOT** for capturing real-time footage. Use something like OBS, SimpleScreenRecorder or FRAPS to achieve that, as they do a much better job at intercepting the compositor than Godot can probably do using Vulkan or OpenGL natively. If your game runs near real-time when capturing, you can still use this feature but it will play no sound (sound will be saved directly).
Usage:
$ godot --write-movie movie.avi [scene_file.tscn]
Missing:
* Options for configuring video writing via GLOBAL_DEF
* UI Menu for launching with this mode from the editor.
* Add to list of command line options.
* Add a feature tag to override configurations when movie writing (fantastic for saving videos with highest quality settings).
This method was meant only as a convenience for editor code
to allow using a step of 0 to disable snapping.
It was exposed by mistake when refactoring GlobalScope.
Add localizable string (Dictionary<Lang Code, String>) property editor and property hint.
Add localized "app name" property to the project settings.
Add localized permission and copyright properties to the macOS and iOS export settings.
Remove some duplicated ("app name") and deprecated ("info") macOS and iOS export properties.
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.
