Fix Area2D/3D not using node rotation for directional gravity

[aaronfranke]

In the current master of Godot, Area2D/3D does not use the rotation of the node for directional gravity. It always behaves as if the node was not rotated. I believe this is a bug because 1) It makes sense to account for rotation and 2) Area2D/3D already accounts for node rotation when using point gravity, so it makes sense to be consistent with the modes.

This technically breaks compatibility as it's a behavior change, but I would guess that this would affect very few users, as probably few users are using gravity at all, and most of those are not rotating gravity fields (or else they'd run into this).

• Bugsquad edit, fixes: Gravity override of Area3D does not take transform into account #79243
• Bugsquad edit, alternative to: Add a setting to control applying area transform to gravity #79268

[AThousandShips]

See also (which is a less invasive change):

• Add a setting to control applying area transform to gravity #79268

And:

• Gravity override of Area3D does not take transform into account #79243

[aaronfranke]

@AThousandShips Good find, I just left a review on the PR. What I did here is the same as the patch in the issue, which is a lot cleaner and more consistent than that PR (though it breaks compat).

[AThousandShips]

I'd argue the behavior should be configurable, and we can easily make it configurable in a way that doesn't break compatibility by having the point gravity customizable as well, but as mentioned there I'm not convinced having the directional gravity always be local is always desired, you can easily work around the limitation if you want it to be local, as mentioned in that PR, but it hasn't been necessarily a major concern, so I'd say people would be more confused by this change than are facing problems with the current situation

I wouldn't consider this a bug, the report for this behavior considers it an enhancement, and it's a matter of opinion if the behavior is desired or not

[aaronfranke]

I'll set this as draft to prevent accidental merging since there is ongoing discussion about the compatibility breakage being too significant. Also note, if PR #82878 is merged, then it will be easier to work around this problem.