Add "Upgrading from Godot 4.4 to Godot 4.5" page #11223
Conversation
raulsntos
added
enhancement
content:new page
| **GLTFAccessor** | ||
| Property ``byte_offset`` changes type metadata from ``int32`` to ``int64`` |✔️| |❌| |❌| `GH-106220`_ | ||
| Property ``component_type`` changes type from ``int`` to ``GLTFAccessor::GLTFComponentType`` |✔️| |❌| |❌| `GH-106220`_ | ||
| Property ``count`` changes type metadata from ``int32`` to ``int64`` |✔️| |❌| |❌| `GH-106220`_ | ||
| Property ``sparse_count`` changes type metadata from ``int32`` to ``int64`` |✔️| |❌| |❌| `GH-106220`_ | ||
| Property ``sparse_indices_byte_offset`` changes type metadata from ``int32`` to ``int64`` |✔️| |❌| |❌| `GH-106220`_ | ||
| Property ``sparse_indices_component_type`` changes type from ``int`` to ``GLTFAccessor::GLTFComponentType`` |✔️| |❌| |❌| `GH-106220`_ | ||
| Property ``sparse_values_byte_offset`` changes type metadata from ``int32`` to ``int64`` |✔️| |❌| |❌| `GH-106220`_ | ||
| **GLTFBufferView** | ||
| Property ``byte_length`` changes type metadata from ``int32`` to ``int64`` |✔️| |❌| |❌| `GH-106220`_ | ||
| Property ``byte_offset`` changes type metadata from ``int32`` to ``int64`` |✔️| |❌| |❌| `GH-106220`_ | ||
| Property ``byte_stride`` changes type metadata from ``int32`` to ``int64`` |✔️| |❌| |❌| `GH-106220`_ |
There was a problem hiding this comment.
This seem like a big breaking change, and these APIs seem to have existed for a while (since 4.0). I don't know if there are many C# users that were using them and would be affected, but it seems we should avoid breaking compatibility in these APIs.
cc @godotengine/import
There was a problem hiding this comment.
@aaronfranke Has changed these. Would like your opinion.
There was a problem hiding this comment.
I think we silently upgraded our apis from 32bit to 64bit due to various errors.
There was a problem hiding this comment.
Compatibility methods are registered for these. I know that fixes GDExtension, but I'm not sure about C#? Anyway...
I don't know if there are many C# users that were using them and would be affected
No, almost nobody was using these APIs. Before PR godotengine/godot#108853 is merged for Godot 4.6, the functions to read/write glTF accessor and buffer data are internal to GLTFDocument, so in the current master of Godot, most of these exposed values aren't useful to user scripts unless they do a lot of manual work.
| **EditorExportPlatformExtension** | ||
| Method ``_get_option_icon`` changes return type from ``ImageTexture`` to ``Texture2D`` |✔️| |❌| |❌| `GH-108825`_ |
There was a problem hiding this comment.
Unfortunately, we can't avoid breaking compat in C# if the method changed the return type. However, this class was added recently (in 4.4), and it's probably not implemented often by C# users (although we can't know for sure). So maybe breaking compatibility here is fine.
cc @godotengine/docks @godotengine/_platforms
|
@raulsntos You should also mention in this document that Android now requires .NET 9 |
| .. note:: | ||
|
|
||
| In C#, ``StringExtensions.PathJoin`` now avoids adding an extra path separator when the original string is empty, | ||
| and when the appended path starts with a path separator (`GH-105281`_). |
There was a problem hiding this comment.
| and when the appended path starts with a path separator (`GH-105281`_). | |
| or when the appended path starts with a path separator (`GH-105281`_). |
If these are two different cases, which based on the PR seems to be the case, both are correct but this is less confusing
| .. note:: | ||
|
|
||
| In C#, the enum ``RenderingDevice.Features`` breaks compatibility because of the way the bindings generator | ||
| detects the enum prefix. New members where added in `GH-103941`_ to the enum that caused the enum member |
There was a problem hiding this comment.
| detects the enum prefix. New members where added in `GH-103941`_ to the enum that caused the enum member | |
| detects the enum prefix. New members where added to the enum in `GH-103941`_ that caused the enum member |
|
It might be good to mention something about godotengine/godot#105746 under "Behavior changes". People who are already using Jolt in 4.4 and are migrating to 4.5 will start to have overlaps reported between Maybe something like: Physics
~~~~~~~
.. note::
When the 3D physics engine is set to Jolt Physics, you will now always have overlaps between ``Area3D`` and static
bodies reported by default, as the ```physics/jolt_physics_3d/simulation/areas_detect_static_bodies``` project setting
has been removed (`GH-105746`_). If you still want such overlaps to be ignored, you will need change the collision mask
or layer of either the ``Area3D`` or the static body instead. |
raulsntos
force-pushed
the
breaking_changes_4.5
branch
from
4d8ccea to
01e331e
Compare
|
As we're running out of time, I'm going to merge this now after giving it a read. If more crops up, we can add to it in further PRs and cherrypick those, as I'm going to branch off |
This documents all the breaking changes in 4.5, like we did for previous versions:
Area maintainers should review the changes listed for their area. Also feel free to suggest any addition that I might have missed or make follow-up PRs.
Updated as of commit godotengine/godot@bfa330d
Preview: https://github.com/raulsntos/godot-docs/blob/breaking_changes_4.5/tutorials/migrating/upgrading_to_godot_4.5.rst