- Based on C++11's `atomic`
- Reworked `SafeRefCount` (based on the rewrite by @hpvb)
- Replaced free atomic functions by the new `SafeNumeric<T>`
- Replaced wrong cases of `volatile` by the new `SafeFlag`
- Platform-specific implementations no longer needed
Co-authored-by: Hein-Pieter van Braam-Stewart <hp@tmm.cx>
- Based on C++14's `shared_time_mutex`
- No more need to allocate-deallocate or check for null
- No pointer anymore, just a member variable
- Platform-specific implementations no longer needed
- Simpler for `NO_THREADS`
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)
Checks whether the signal exists when issuing an error message when
disconnecting a nonexistent connection. Also prints the callable name.
(cherry picked from commit 6c026a6814)
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.
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.
We used a lock signals in the signal_map while emitting, because it was
not allowed to disconnect them while being emitted.
We used that lock to check if we where deleting an object during signal
emission.
Now that we allow to disconnect signals while they are being emitted, if
an object first disconnects, then gets deleted we can't know that a
signal was being emitted during the destructor.
This commit adds a new `_emitting` boolean member to Object to be set
while emitting and checked in the destructor, while removing the old
signal lock which is now unused.
According to 22637beb2e (commitcomment-36651823)
and as confirmed by @reduz, this seems not to be necessary now that we
copy-on-write.
This triggered freeze scenarios in cases where a node would be deleted
while being used as a target in a signal emission.
Fixes#34650.
Fixes#34769.
Now those two errors go back to reporting:
```
ERROR: emit_signal: Condition ' !target ' is true. Continuing..:
At: core/object.cpp:1191.
```
It will now give information about the originating object instance
and when locked, the target callback.
This should help debugging editor and game issues that are now being
reported due to adding signal locking in
22637beb2e.
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.
Condensed some if and ERR statements. Added dots to end of error messages
Couldn't figure out EXPLAINC. These files gave me trouble: core/error_macros.h, core/io/file_access_buffered_fa.h (where is it?),
core/os/memory.cpp,
drivers/png/png_driver_common.cpp,
drivers/xaudio2/audio_driver_xaudio2.cpp (where is it?)
All 100% completed: MainLoop, Node, Object, Path, Performance,
Reference, Resource, SceneState, SceneTree, UndoRedo.
Also fixed some en_GB occurrences as the reference spelling is en_US.
Object::get_indexed was not correctly reporting invalid keys if the name
was a direct property (not a subproperty), causing for example Tween to
not report correctly a bad interpolate_property key.
Reasoning: ID is not an acronym, it is simply short for identification, so it logically should not be capitalized. But even if it was an acronym, other acronyms in Godot are not capitalized, like p_rid, p_ip, and p_json.
solves #26796
- ADD `String to_string()` method to Object which can be overriden by `String _to_string()` in scripts
- ADD `String to_string(r_valid)` method to ScriptInstance to allow langauges to control how scripted objects are converted to strings
- IMPLEMENT to_string for GDScriptInstance, VisualScriptInstance, and NativeScriptInstance
- ADD Documentation about `Object.to_string` and `Object._to_string`
- Changed `Variant::operator String` to use `obj->to_string()`
It appears that Object::script may be a valid ScriptInstance but not be
castable to Ref<Script>. There were only 5 places in the code that made
this assumption. This commit fixes that.
It seems to stay compatible with formatting done by clang-format 6.0 and 7.0,
so contributors can keep using those versions for now (they will not undo those
changes).
Only possible if the object class is a "native type". If the object class is a user class (that derives a "native type") then a script is needed.
Since CSharpLanguage does cleanup of script instance bindings when finished, cases like #25621 will no longer cause problems.
Fixed ~Object() trying to free script instance bindings after the language has already been removed, which would result in a NULL dereference.
