- Fixed floating point issue on the old one.
- Fixed the equation on the get_euler_yxz function.
- Added unit tests.
This work has been kindly sponsored by IMVU.
Fixes#36372 as Path2D/Path3D's `curve` property no longer uses a Curve
instance as default value, but instead it gets a (unique) default Curve
instance when created through the editor (CreateDialog).
ClassDB gets a sanity check to ensure that we don't do the same mistake
for other properties in the future, but instead use the dedicated
property usage hint.
Fixes#36372.
Fixes#36650.
Supersedes #36644 and #36656.
Co-authored-by: Thakee Nathees <thakeenathees@gmail.com>
Co-authored-by: simpuid <utkarsh.email@yahoo.com>
Note:
Casting to the C++ classes and calling the methods there would work as well,
but would require including he header files for the specific object types handled
here, which wouldn't be OK either.
Each time `r_err_str` is set, we should return a parse error.
Removed redundant `return OK;` which were already handled after the big
`if`/`else if`/`else` for `TK_IDENTIFIER`.
Part of #17372.
Godot currently supports zero padding for integers, octals and
hexadecimals when using format strings, but not for floats.
This commit adds support for zero padding for floats, thus ensuring
consistent behavior for all types, and making Godot's format specifiers'
behavior closer to c's `printf()`.
Before: `print("<%07.2f>" % -0.2345)` prints `< -0.23>`.
Now: `print("<%07.2f>" % -0.2345)` prints `<-000.23>`.
`print("<%7.2f>" % -0.2345)` prints `< -0.23>`.
`erase()` calls `find()` to get the index of the element to remove, if
any.
https://github.com/godotengine/godot/blob/c2151e18135817c9f926a5a00341016ac77301d4/core/local_vector.h#L77-L81
`find()` returns a signed integer. In particular, it returns -1 if
no element is found. Since `erase()` converts this to an unsigned type, the
wrong element may be erroneously removed from the vector.
Other ways to fix this would involve changing function signatures, so
this seemed to be the least disruptive change.
Fixes#38884
Semicolons are not necessary after function definitions or control flow
blocks, and having some code use them makes things inconsistent (and
occasionally can mess up `clang-format`'s formatting).
Removing them is tedious work though, I had to do this manually (regex
+ manual review) as I couldn't find a tool for that. All other code
folders would need to get the same treatment.
Fabio Alessandrelli