There's still some fishy recursive relationship between `load_interactive` and
`load` which needs to be investigated here, but this patch solves the crash
when returning an error code in user-defined `load`.
Fixes#48463.
(cherry picked from commit bf9f288c7d)
This will enforce that PRs properly sync the class reference templates to match
their changes to the public API, and help notice binding bugs in the process
(e.g. missing enum bindings, unexpected API changes or missing argument names).
This should also serve as a reminder to contributors that their changes impact
the scripting API and might warrant actually filling the descriptions for the
new methods/properties/etc.
(cherry picked from commit b388412270)
Since we clone the environments to build thirdparty code, we don't get an
explicit dependency on the build objects produced by that environment.
So when we update thirdparty code, Godot code using it is not necessarily
rebuilt (I think it is for changed headers, but not for changed .c/.cpp files),
which can lead to an invalid compilation output (linking old Godot .o files
with a newer, potentially ABI breaking version of thirdparty code).
This was only seen as really problematic with bullet updates (leading to
crashes when rebuilding Godot after a bullet update without cleaning .o files),
but it's safer to fix it everywhere, even if it's a LOT of hacky boilerplate.
(cherry picked from commit c7b53c03ae)
(cherry picked from commit e94161dada)
Fix for a regression from software skinning support:
instance_attach_skeleton wasn't called in set_mesh before, and it's
causing issues when the mesh instance is loaded from a thread.
1. Call from a thread queues instance_attach_skeleton with RID() in the
visual server.
2. Call from the main thread when entering tree calls
instance_attach_skeleton immediately with a valid skeleton
3. Queued instance_attach_skeleton resets the attached skeleton
This change prevents that to happen by making sure
instance_attach_skeleton is not called on set_mesh as it was doing
before, but there might be a more general problem to solve in how
visual server commands are executed when resources are loaded from
a different thread.
(cherry picked from commit feee9f9695)
All my earlier test cases for software skinning had the polys parent transform to be identity. This works fine until you had cases where the user had moved the transform of the parent nodes of skinned polys.
This PR fixes this situation by taking into account the final (concatenated) transform of the polys RELATIVE to the skeleton base transform. It does this by applying the inverse skeleton base transform to the poly final transform.
(cherry picked from commit f33e22001f)
It seems 30.0.1 had issues with compatibility with JDK 8 and 11,
which appear to be solved in 30.0.3 as per godotengine/godot-docs#4796.
(cherry picked from commit d88e1f04df)
We still use Emscripten 1.39.9 for official Mono builds so ideally we want to test
against an old Emscripten version to ensure we don't break compatibility.
But then google-closure-compiler-linux broke compatibility for us and is not properly
pinned, so we need to use a more recent version for now to fix CI.
Cf. https://github.com/emscripten-core/emsdk/issues/802
(cherry picked from commit 9571ae3a33)
After further testing it seems to work fine now when building binaries with GCC 5
on Ubuntu 16.04 (previously we were using GCC 9 on Ubuntu 14.04).
Follow-up to #45629.
(cherry picked from commit aa15ad72ee)
paru
clayjohn
Rémi Verschelde
TwistedTwigleg
Lightning_A
rafallus
kobewi
MaxStgs
PouleyKetchoupp
Hugo Locurcio
CaptainProton42
Brian Semrau
JFonS
Mateo Kuruk Miccino
Koala
kleonc
lawnjelly
bruvzg
Sergey Minakov
Fabio Alessandrelli
thebestnom
smix8
David Snopek
Johannes Witt
skyace65
Thomas ten Cate
ray90514
Marcel Admiraal