This is a backport from 4.0 to 3.x that adds 'sort' and 'has' methods
to the following types:
- PoolByteArray
- PoolIntArray
- PoolRealArray
- PoolStringArray
- PoolVector2Array
- PoolVector3Array
- PoolColorArray
For all the types above, the methods 'sort' and 'has' have been
exposed to the GDNative API (v. 1.3)
Since the method 'has' was already implemented in GDScript before,
in this commit it has been only exposed to GDNative API.
The classes documentation is updated.
The method 'sort' uses the exisging class "Sorter".
Pooled arrays in 4.0 are rewritten, that's why this backport is not
completely indentical to the original PR made for 4.0 (see #32144).
* Adds `indent(prefix)` to `String`
* Moves the loading of tool/doc translation into
`editor/editor_translation.{h,cpp}`
* Makes use of doc translation when generating XML class references, and
setup the translation locale based on `-l LOCALE` CLI parameter.
The XML class reference won't be translated if `-l LOCALE` parameter is
not given, or when it's `-l en`.
Extra:
- Optimized the debug-only check about why the object is null to determine if it's because it has been deleted (the RC is enough; no need to check the ObjectDB).
- Because of the previous point. the debugger being attached is not required anymore for giving the "Object was deleted" error; from now, it only matters that it's a debug build.
- `is_instance_valid()` is now trustworthy. It will return `true` if, and only if, the last object assigned to a `Variant` is still alive (and not if a new object happened to be created at the same memory address of the old one).
- Replacements of `instance_validate()` are used where possible `Variant::is_invalid_object()` is introduced to help with that. (GDScript's `is_instance_valid()` is good.)
We've been using standard C library functions `memcpy`/`memset` for these since
2016 with 67f65f6639.
There was still the possibility for third-party platform ports to override the
definitions with a custom header, but this doesn't seem useful anymore.
Backport of #48239.
Happy new year to the wonderful Godot community!
2020 has been a tough year for most of us personally, but a good year for
Godot development nonetheless with a huge amount of work done towards Godot
4.0 and great improvements backported to the long-lived 3.2 branch.
We've had close to 400 contributors to engine code this year, authoring near
7,000 commit! (And that's only for the `master` branch and for the engine code,
there's a lot more when counting docs, demos and other first-party repos.)
Here's to a great year 2021 for all Godot users 🎆
(cherry picked from commit b5334d14f7)
- 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.
(cherry picked from commit 2331300989)
This moves the instance id member from Variant to the ObjectRC so that Variant is still the same size as before the fix (and also regardless if debug or release build).
This commit addresses multiple issues with `Variant`s that point to an `Object`
which is later released, when it's tried to be accessed again.
Formerly, **while running on the debugger the system would check if the instance id was
still valid** to print warnings or return special values. Some cases weren't being
warned about whatsoever.
Also, a newly allocated `Object` could happen to be allocated at the same memory
address of an old one, making cases of use hard to find and having **`Variant`s pointing
to the old one magically reassigned to the new**.
This commit makes the engine realize all these situations **under debugging**
so you can detect and fix them. Running without a debugger attached will still
behave as it always did.
Also the warning messages have been extended and made clearer.
All that said, in the name of performance there's still one possible case of undefined
behavior: in multithreaded scripts there would be a race condition between a thread freeing
an `Object` and another one trying to operate on it. The latter may not realize the
`Object` has been freed soon enough. But that's a case of bad scripting that was never
supported anyway.
Happy new year to the wonderful Godot community!
We're starting a new decade with a well-established, non-profit, free
and open source game engine, and tons of further improvements in the
pipeline from hundreds of contributors.
Godot will keep getting better, and we're looking forward to all the
games that the community will keep developing and releasing with it.
