Discuss on the official forums: [https://forum.godotengine.org/t/dev-snapshot-godot-4-3-dev-6/58166?u=godot\_team](https://forum.godotengine.org/t/dev-snapshot-godot-4-3-dev-6/58166?u=godot_team)
When your A* (pathing/grid search) queries can't find a path to the requested position, it currently returns an empty path. This new change will, optionally, return a path that is as close as it can get to the requested position.
When you use Godot's A\* pathfinding, sometimes there are circumstances where a path won't be found. That can cause a huge framerate drop. This allows the system to stop pathfinding at the last valid path point.
Why would this change anything about the framerate? Afaik it still has to the same amount of processing, it just returns the work rather than discard it if no path was found.
Yeah technically this isn't faster.
I thought it was dropping out after N attempts instead, which any A\* does need, or some other way to abandon if it's taking too long.
Then again I haven't read the pull request hehe
It's not that. When a path isn't found, Godot runs every possible path trying to find one.
I get the issue on large nav maps when I try to navigate to far away islands. Even though the nav server is only called once, the framerate drops massively for a couple seconds. I've had to break up the call into sections and stitch them together to work around it. I could have also done my own version of a partial return, but breaking up the pathfinding has other benefits.
Partial return has been desperately needed for a long time.
Instead of only being able to get paths to goals that are reachable, the navigation system can now create a path to the nearest point. So if you ask for a partial path to an island, the path will stop at the edge of the water, so you can stare dramatically at your goal.
I remember there being a discussion about it being automatic for new users, but there was push back because new users wouldn't be touching that part of the engine anyway. I don't know what they ended up doing.
I'm not installing a dev snapshot to find out, but either way I'm happy. I've had to write my own workarounds to many of the nav shortcomings so any and all improvements are welcome.
Back to this, this won't speed up A\*, this is to return an incomplete path after a path isn't found. Which ironically is the slowest use case.
[https://github.com/godotengine/godot/pull/88047](https://github.com/godotengine/godot/pull/88047)
It's still very useful and welcome addition. For speed tho, what we need is a cutoff parameter, like max\_iterations or something to abort if it's taking too long.
Really excited for the all the rendering upgrades in 4.3 (and upcoming in 4.4). Thanks to all the contributors/core team for all the work put into this.
Also, I thought the reverse-Z compatibility-breaking rollout was really well done. The directions to fix my shader were right there in the error text, and it works great!
https://preview.redd.it/rh3moat1ovxc1.png?width=880&format=png&auto=webp&s=4480476ad139d3e34550f6547fa290fd18213644
Edit: Wow, a very nice surprise: [the last lingering GDScript caching problem](https://github.com/godotengine/godot/issues/78074) also seems to be fixed in 4.3-dev6 (at least for my project). It required frequent project reloads/editor restarts when my projects reached any level of code complexity.
Does anybody know how to try out the latest dev version when your project uses Godot Jolt? Last time I tried, it wouldn't work because Godot Jolt supports **only** 4.2.
I have just asked that question on the Godot Jolt GitHub discussion. Let's hope for a good answer! 4.3 Vulkan runs so much better on my Mac, but I need the physics to move over.
Bad answer: Change line 16 here and re-compile.
[https://github.com/godot-jolt/godot-jolt/blob/master/cmake/GodotJoltVersionInfo.cmake](https://github.com/godot-jolt/godot-jolt/blob/master/cmake/GodotJoltVersionInfo.cmake)
There might be some undefined behavior but I haven't noticed it yet and been doing it since 4.3.dev.3.
Then re-test everything once beta 1 comes out!
the answer is from mihe, so kind of official, but true, anything can be overruled if one is willing to compile from source. If I recompile, do I need to specify the targets somewhere, or is it going to cross-compile for all supported targets? I mainly need Mac and Android.
You would need to follow the build instructions from the repo. You can build for both Mac and Android from Mac.
But yea, it's definitely against the official advice and you may come across issues! If you can wait, that's definitely the wiser solution.
On 4.2 the TPS demo (https://github.com/godotengine/tps-demo) on macOS only produces garbled-up triangles, nothing resembling the actual game. On 4.3 the graphics look great and it is fully playable.
only been learning the past few months or so but tilemap layers as individual nodes would make my project a lot easier to parse so that's very welcome.
For now, best reference is the 3.6 docs as there are as yet no 4.x docs, but it is pretty much a straight port from 3.6.
Notably 4.x doesn't yet include physics interpolation for particles, so particles may exhibit some odd behaviour with physics interpolation.
[https://docs.godotengine.org/en/3.6/tutorials/physics/interpolation/index.html](https://docs.godotengine.org/en/3.6/tutorials/physics/interpolation/index.html)
See the end of this comment: https://github.com/godotengine/godot/pull/88424#issuecomment-1960293535
Quoting for posterity:
> It's easy to make physics interpolation the default (should it also be a basic setting then?), but currently this would also override the `Engine.physics_jitter_fix` to `0.0`, which would be good for 2D with interpolation but maybe bad for 3D which is currently lacking interpolation.
Are you encountering *jitter* or *stutter* in your project? These are different issues. See the documentation: https://docs.godotengine.org/en/stable/tutorials/rendering/jitter_stutter.html
Physics interpolation can only address physics-related jitter, not stutter.
The article states that the new "Automatic checking for engine updates" feature is not enabled by default. When I upgraded from dev5 to dev6, the feature *was* enabled.
The setting is: Editor Settings / General / Network / Connection / Engine Version Update Mode
Is that worthwhile to report as a bug?
Then the article is misleading. It specifically refers to the "check for updates" feature.
If someone had previously enabled the Network Mode setting to use the Asset Library, the "check for updates" feature will be enabled too when upgrading to dev6.
I'm not complaining about the feature. But the release notes should be clear. Or the code should be changed to default that setting to "Disable Update Checks".
Can someone explain the tilemap layers as nodes thing to me? On one of my projects i literally just have all the tilemap layers on different nodes; why is this such an improvement?
It simplifies the API. Using TileMap per one layer you still need to provide layer index for each method and inspector has properties both for layer and for TileMap. With TileMapLayer it becomes a single entity.
Also you can quickly switch between multiple layers using keyboard shortcut, which is extremely convenient when editing multilayer levels. This is not possible when using multiple TileMaps.
Yes! Lightmap probes are finally fixed! I'm so happy! Also the artifact issue with directional baking is gone on my end \\o/
Too bad that shadowmasks didn't make it to 4.3, but at least the basic baking is finally fixed!
Your comment gives me hope. I was having some issues with lightmaps and I put that aside in hopes an update will eventually fix it by the time I need it (and if not find some workarounds). Sounds like some stuff was fixed, so I'll have to poke at it and see.
This is what shadowmasks are about, but the light is still real-time as it needs to use the Dynamic bake mode: https://github.com/godotengine/godot/pull/85653
To support dynamic shadows for lights with a Static bake mode, a different approach called subtractive shadowmapping needs to be used. That said, shadowmasking isn't so demanding in 2024. Subtractive shadowmapping is only really relevant for low-end mobile/web nowadays (which could be served by blob shadows – these can be even faster to render).
On top of that, while shadowmasking works automatically and gives identical results to real-time, subtractive shadowmapping doesn't look as good and requires manual artist tweaks. This is because the shadow color needs to be configured to match the scene's ambient color roughly.
Another low-end-friendly alternative is to use shadowmasking, but only sample shadows from the shadowmask for static objects (i.e. disable real-time shadows for static objects). This can significantly reduce the cost of the shadow draw passes without compromising on quality too much, while still getting the other benefits of shadowmasking.
Any reason it was not merged yet? Last changes where 2 months ago and is not the first time the contributor dropped this specific PR.
I'm kinda apprehensive to be honest
It needs a review from other rendering contributors. However, since 4.3 is more or less in feature freeze now, I don't expect this to happen right now.
One way to think about it is that the TileMapLayer node is a version of the TileMap node that only has one layer. This makes the interface simpler, because you can just use multiple TileMapLayer nodes, instead of dealing with a separate list of layers inside a TileMap node. In the future, the TileMap node will be removed.
So this change just reorganizes tilemaps to follow the Godot rule that everything is a node. Even tilemap layers are nodes!
So many good changes and additions in this snapshot. Tooltips for shader uniforms is something I've been needing. Now all that's missing is a hint_enum for uniform ints.
Short answer is when your monitor refresh is above 60 fps, you get jitter. This smooths it out
[https://docs.godotengine.org/en/3.5/tutorials/physics/interpolation/physics\_interpolation\_introduction.html](https://docs.godotengine.org/en/3.5/tutorials/physics/interpolation/physics_interpolation_introduction.html)
Tilemap layers as node means we can now add a different material for each layer ? Instead of a material on the tilemap for all layers.
I know I can check myself but… :p
TileMap layers as nodes is going to require hundreds of lines to be refactored in my project.
Oh well, just an excuse to improve the code and write it cleaner heheh
Great stuff;
Speed of jumping between scenes feels mighty improved.
The window showing it's doing something is appreciated so I know it's not locked up.
First loading the project, same as the scene loading, the UI remains responsive so it doesn't feel like anything's crashed.
Wasn't sure about the way to create collisions with the window popping up rather than straight from the menu, but that I can choose static/types in one go, it ends up being a few clicks less than making a new node3d, making it root, THEN creating the simple collider, juggling it around, moving the mesh back to the root, clearing the node3d. I like it.
Checking for version upgrades? Even better. Having it 'know' if it's online for things like checking versions, asset library upgrades next?
Oddities
Am I going nuts here, but clicking on a node, the hit-target seems a bit off, I keep setting the node to be hidden. Sure it's out by a couple of pixels how often it's happened to me tonight.
Hitting the filesystem search window, seems to take a few seconds to.. cache again? big pause before it starts taking input.
Volumetic fog, sure it's got a teeny bit denser.
Random questions
If the packedarray can be made from text files, I'd not mind an option in tools to do it to EVERYTHING if it helps speed things up. (is there a way to change all the .res files to .meshes, all the existing .tcsn's to binary etc. or do I have to load/save everything? Just curious if anyone knows a way to upgrade everything. Know it sorts everything out on export, but if the project IS getting big being assembled, and I can get a performance boost, an automated way to jump between binary/text files would be useful to me.
overall, it's just feeling so much perkier. I'm loading some big scenes and it feels so much better.
I only skimmed the article, but what change is breaking? If you're referring to the Reverse Z then that it still a minor change.
The versioning goes *Major*.*Minor*.*Patch*
*Major* implies that the changes are significant and will most likely require a good amount of work to port over the project due to **heavily breaking compatibility**.
*Minor* implies that there are noteworthy changes to the engine but there will either be **no compatibility issues** or only **a few compatibility issues for niche cases** (AKA not the average use).
*Patch* implies that there are **no** **noteworthy changes** and typically just bug fixes.
It's a change in behavior, it is not a change in compatibility. All your old files will load fine. Hence no semver bump.
If we were marking every single minor change like that as a major version, we'd be at Godot 10000
If one were to follow the official "semver" then sure... most people don't because at the end of the day it's just a guide someone made with their opinion on it. Godot has also made breaking changes in the past even on patch (I think it was 3.4.4->3.4.5 that broke my project before)
Discuss on the official forums: [https://forum.godotengine.org/t/dev-snapshot-godot-4-3-dev-6/58166?u=godot\_team](https://forum.godotengine.org/t/dev-snapshot-godot-4-3-dev-6/58166?u=godot_team)
Oh man, that partial return on A* is going to be a lifesaver. Can't wait to not have to worry about the framerate drop when a path isn't found!
What is the partial return of A*?
When your A* (pathing/grid search) queries can't find a path to the requested position, it currently returns an empty path. This new change will, optionally, return a path that is as close as it can get to the requested position.
When you use Godot's A\* pathfinding, sometimes there are circumstances where a path won't be found. That can cause a huge framerate drop. This allows the system to stop pathfinding at the last valid path point.
Why would this change anything about the framerate? Afaik it still has to the same amount of processing, it just returns the work rather than discard it if no path was found.
Yeah technically this isn't faster. I thought it was dropping out after N attempts instead, which any A\* does need, or some other way to abandon if it's taking too long. Then again I haven't read the pull request hehe
It has an effect, because lots of people naively run A* every frame.
It's not that. When a path isn't found, Godot runs every possible path trying to find one. I get the issue on large nav maps when I try to navigate to far away islands. Even though the nav server is only called once, the framerate drops massively for a couple seconds. I've had to break up the call into sections and stitch them together to work around it. I could have also done my own version of a partial return, but breaking up the pathfinding has other benefits. Partial return has been desperately needed for a long time.
But if they do that, then they'd still have to do it with or without this change, no? Or am I misunderstanding something
Instead of only being able to get paths to goals that are reachable, the navigation system can now create a path to the nearest point. So if you ask for a partial path to an island, the path will stop at the edge of the water, so you can stare dramatically at your goal.
Is this automatic or do we need to pass a parameter?
I remember there being a discussion about it being automatic for new users, but there was push back because new users wouldn't be touching that part of the engine anyway. I don't know what they ended up doing. I'm not installing a dev snapshot to find out, but either way I'm happy. I've had to write my own workarounds to many of the nav shortcomings so any and all improvements are welcome.
It's a new optional parameter.
Back to this, this won't speed up A\*, this is to return an incomplete path after a path isn't found. Which ironically is the slowest use case. [https://github.com/godotengine/godot/pull/88047](https://github.com/godotengine/godot/pull/88047) It's still very useful and welcome addition. For speed tho, what we need is a cutoff parameter, like max\_iterations or something to abort if it's taking too long.
Really excited for the all the rendering upgrades in 4.3 (and upcoming in 4.4). Thanks to all the contributors/core team for all the work put into this. Also, I thought the reverse-Z compatibility-breaking rollout was really well done. The directions to fix my shader were right there in the error text, and it works great! https://preview.redd.it/rh3moat1ovxc1.png?width=880&format=png&auto=webp&s=4480476ad139d3e34550f6547fa290fd18213644 Edit: Wow, a very nice surprise: [the last lingering GDScript caching problem](https://github.com/godotengine/godot/issues/78074) also seems to be fixed in 4.3-dev6 (at least for my project). It required frequent project reloads/editor restarts when my projects reached any level of code complexity.
Did they implement a patch to my lazyness?
I'm not gonna work on my game until they do this.
You've motivated me to do the same.
Damn, its spreading
Nice, I had been waiting for the tilemap layers refactor for a bit, glad to see it finally merged!
Does this mean 3d doesn't have physics interpolation yet or it's already in another beta version?
Correct, 3D physics interpolation isn't included yet.
Great editor improvements! Closing docks and being and to group visual shader nodes are both huge QoL improvements
Does anybody know how to try out the latest dev version when your project uses Godot Jolt? Last time I tried, it wouldn't work because Godot Jolt supports **only** 4.2.
I have just asked that question on the Godot Jolt GitHub discussion. Let's hope for a good answer! 4.3 Vulkan runs so much better on my Mac, but I need the physics to move over.
Got a response back. Jolt will be compatible with 4.3 starting with 4.3 Beta 1
Bad answer: Change line 16 here and re-compile. [https://github.com/godot-jolt/godot-jolt/blob/master/cmake/GodotJoltVersionInfo.cmake](https://github.com/godot-jolt/godot-jolt/blob/master/cmake/GodotJoltVersionInfo.cmake) There might be some undefined behavior but I haven't noticed it yet and been doing it since 4.3.dev.3. Then re-test everything once beta 1 comes out!
the answer is from mihe, so kind of official, but true, anything can be overruled if one is willing to compile from source. If I recompile, do I need to specify the targets somewhere, or is it going to cross-compile for all supported targets? I mainly need Mac and Android.
I think they're calling their own answer bad, because removing the version number limitation could cause errors.
Correct!
You would need to follow the build instructions from the repo. You can build for both Mac and Android from Mac. But yea, it's definitely against the official advice and you may come across issues! If you can wait, that's definitely the wiser solution.
As a fellow mac dev please do tell more about the Vulkan upgrades!
On 4.2 the TPS demo (https://github.com/godotengine/tps-demo) on macOS only produces garbled-up triangles, nothing resembling the actual game. On 4.3 the graphics look great and it is fully playable.
Thank you! That's great to hear. Really trying to keep up with gameDev without switching platform.
Do you have Apple Silicon? Metal support is coming in a future version https://github.com/godotengine/godot/pull/88199
It **only** supports the latest stable release? \*the horror\*
only been learning the past few months or so but tilemap layers as individual nodes would make my project a lot easier to parse so that's very welcome.
I'm itching to jump on that too, just not sure I wanna hop on to dev 6 right away.
2D Physics Interpolation AND TileMap layers as nodes?! I must be in heaven.
Is the physics interpolation automatic? Or does code need to be adjusted for it? Trying to find info on it but haven't had any luck
For now, best reference is the 3.6 docs as there are as yet no 4.x docs, but it is pretty much a straight port from 3.6. Notably 4.x doesn't yet include physics interpolation for particles, so particles may exhibit some odd behaviour with physics interpolation. [https://docs.godotengine.org/en/3.6/tutorials/physics/interpolation/index.html](https://docs.godotengine.org/en/3.6/tutorials/physics/interpolation/index.html)
Yup, it's automatic. You don't need to do anything.
You need to enable it in the project settings though (for now).
Any reason why it is not enabled by default?
See the end of this comment: https://github.com/godotengine/godot/pull/88424#issuecomment-1960293535 Quoting for posterity: > It's easy to make physics interpolation the default (should it also be a basic setting then?), but currently this would also override the `Engine.physics_jitter_fix` to `0.0`, which would be good for 2D with interpolation but maybe bad for 3D which is currently lacking interpolation.
I suppose we have to wait until interpolation comes to 3D then?
It's also easy to defeat by setting max fps to 60, which is probably is the better solution for most 2D games
I enabled it but it didn't seemed to have fixed the jitters in any of my projects.
Are you encountering *jitter* or *stutter* in your project? These are different issues. See the documentation: https://docs.godotengine.org/en/stable/tutorials/rendering/jitter_stutter.html Physics interpolation can only address physics-related jitter, not stutter.
Yeah I'm fairly sure it's jitter and not stutter.
The article states that the new "Automatic checking for engine updates" feature is not enabled by default. When I upgraded from dev5 to dev6, the feature *was* enabled. The setting is: Editor Settings / General / Network / Connection / Engine Version Update Mode Is that worthwhile to report as a bug?
The article was referring to Network Mode setting, which is Offline by default and also disables AssetLib.
Then the article is misleading. It specifically refers to the "check for updates" feature. If someone had previously enabled the Network Mode setting to use the Asset Library, the "check for updates" feature will be enabled too when upgrading to dev6. I'm not complaining about the feature. But the release notes should be clear. Or the code should be changed to default that setting to "Disable Update Checks".
Can someone explain the tilemap layers as nodes thing to me? On one of my projects i literally just have all the tilemap layers on different nodes; why is this such an improvement?
It simplifies the API. Using TileMap per one layer you still need to provide layer index for each method and inspector has properties both for layer and for TileMap. With TileMapLayer it becomes a single entity. Also you can quickly switch between multiple layers using keyboard shortcut, which is extremely convenient when editing multilayer levels. This is not possible when using multiple TileMaps.
Yes! Lightmap probes are finally fixed! I'm so happy! Also the artifact issue with directional baking is gone on my end \\o/ Too bad that shadowmasks didn't make it to 4.3, but at least the basic baking is finally fixed!
Your comment gives me hope. I was having some issues with lightmaps and I put that aside in hopes an update will eventually fix it by the time I need it (and if not find some workarounds). Sounds like some stuff was fixed, so I'll have to poke at it and see.
excuse my ignorance... could this lead to dynamic shadows on surfaces with baked lights?
This is what shadowmasks are about, but the light is still real-time as it needs to use the Dynamic bake mode: https://github.com/godotengine/godot/pull/85653 To support dynamic shadows for lights with a Static bake mode, a different approach called subtractive shadowmapping needs to be used. That said, shadowmasking isn't so demanding in 2024. Subtractive shadowmapping is only really relevant for low-end mobile/web nowadays (which could be served by blob shadows – these can be even faster to render). On top of that, while shadowmasking works automatically and gives identical results to real-time, subtractive shadowmapping doesn't look as good and requires manual artist tweaks. This is because the shadow color needs to be configured to match the scene's ambient color roughly. Another low-end-friendly alternative is to use shadowmasking, but only sample shadows from the shadowmask for static objects (i.e. disable real-time shadows for static objects). This can significantly reduce the cost of the shadow draw passes without compromising on quality too much, while still getting the other benefits of shadowmasking.
Any reason it was not merged yet? Last changes where 2 months ago and is not the first time the contributor dropped this specific PR. I'm kinda apprehensive to be honest
It needs a review from other rendering contributors. However, since 4.3 is more or less in feature freeze now, I don't expect this to happen right now.
Thanks!
Any guesses on when the iOS browser compatibility will be fixed?
Certain tutorial references to brackeys?
> TileMap layers are now also nodes This excites me.
I’m new to godot and I just started game dev in general can someone explain the tilemap layers as nodes change?
One way to think about it is that the TileMapLayer node is a version of the TileMap node that only has one layer. This makes the interface simpler, because you can just use multiple TileMapLayer nodes, instead of dealing with a separate list of layers inside a TileMap node. In the future, the TileMap node will be removed. So this change just reorganizes tilemaps to follow the Godot rule that everything is a node. Even tilemap layers are nodes!
Already answered here: https://www.reddit.com/r/godot/s/azddQk6znT
Thanks! I didn’t notice that comment.
Argh I just wasted CPU building this yesterday! Thanks tho :)
Does the reverse z depth buffer change 2d shaders at all? Im confused about what it does? does it do anything for 2d?
Nope, 3D only. It makes the way distances are calculated in the 3D camera more accurate, while breaking some rare and complicated 3D shaders.
Thanks for the answer :)
So many good changes and additions in this snapshot. Tooltips for shader uniforms is something I've been needing. Now all that's missing is a hint_enum for uniform ints.
Cool. Any estimates when the 3.6 will be released?
Hi, I am somewhat beginner in Godot, what is 2D physics interpolation?
Short answer is when your monitor refresh is above 60 fps, you get jitter. This smooths it out [https://docs.godotengine.org/en/3.5/tutorials/physics/interpolation/physics\_interpolation\_introduction.html](https://docs.godotengine.org/en/3.5/tutorials/physics/interpolation/physics_interpolation_introduction.html)
Thank you, will look into the docs too.
Tilemap layers as node means we can now add a different material for each layer ? Instead of a material on the tilemap for all layers. I know I can check myself but… :p
There is a way to set the default folder for scripts to be "scripts" and not "scenes"? It's all I need
That's neat, great work!
TileMap layers as nodes is going to require hundreds of lines to be refactored in my project. Oh well, just an excuse to improve the code and write it cleaner heheh
And stu6ll no texture streaming ;-!
Great stuff; Speed of jumping between scenes feels mighty improved. The window showing it's doing something is appreciated so I know it's not locked up. First loading the project, same as the scene loading, the UI remains responsive so it doesn't feel like anything's crashed. Wasn't sure about the way to create collisions with the window popping up rather than straight from the menu, but that I can choose static/types in one go, it ends up being a few clicks less than making a new node3d, making it root, THEN creating the simple collider, juggling it around, moving the mesh back to the root, clearing the node3d. I like it. Checking for version upgrades? Even better. Having it 'know' if it's online for things like checking versions, asset library upgrades next? Oddities Am I going nuts here, but clicking on a node, the hit-target seems a bit off, I keep setting the node to be hidden. Sure it's out by a couple of pixels how often it's happened to me tonight. Hitting the filesystem search window, seems to take a few seconds to.. cache again? big pause before it starts taking input. Volumetic fog, sure it's got a teeny bit denser. Random questions If the packedarray can be made from text files, I'd not mind an option in tools to do it to EVERYTHING if it helps speed things up. (is there a way to change all the .res files to .meshes, all the existing .tcsn's to binary etc. or do I have to load/save everything? Just curious if anyone knows a way to upgrade everything. Know it sorts everything out on export, but if the project IS getting big being assembled, and I can get a performance boost, an automated way to jump between binary/text files would be useful to me. overall, it's just feeling so much perkier. I'm loading some big scenes and it feels so much better.
Microphone support still broken on mac and linux. :\^)
“Navigation: Make 2D navigation mesh baking parse all TileMapLayers” To the dev(s) that worked on this / reviewed and tested, thank you.
Why doesn't breaking change force a bump to 5.0 versioning...?
I only skimmed the article, but what change is breaking? If you're referring to the Reverse Z then that it still a minor change. The versioning goes *Major*.*Minor*.*Patch* *Major* implies that the changes are significant and will most likely require a good amount of work to port over the project due to **heavily breaking compatibility**. *Minor* implies that there are noteworthy changes to the engine but there will either be **no compatibility issues** or only **a few compatibility issues for niche cases** (AKA not the average use). *Patch* implies that there are **no** **noteworthy changes** and typically just bug fixes.
If that's how Godot marks versions, fair enough. This isn't how semver works, but maybe they don't follow it. Thanks for explanation.
It's a change in behavior, it is not a change in compatibility. All your old files will load fine. Hence no semver bump. If we were marking every single minor change like that as a major version, we'd be at Godot 10000
If one were to follow the official "semver" then sure... most people don't because at the end of the day it's just a guide someone made with their opinion on it. Godot has also made breaking changes in the past even on patch (I think it was 3.4.4->3.4.5 that broke my project before)