Setting a CircleShape2D's radius inside a script does not update the physics engine.

[TravisBarryDick]

Describe the bug

When a script changes the radius of a RigidBody2D's CollisionShape2D's CircleShape2D, the body still collides as though the radius was not changed.

To Reproduce
Steps to reproduce the behavior:

1. Create a Scene with a RigidBody2D > CollisionShape2D subtree and set the CollisionShape2D's shape to be a CircleShape2D with a small radius.
2. Add a StaticBody2D for the RigidBody to fall onto and collide with.
3. Attach a script to the RigidBody2D with

func _ready():
    $CollisionShape2D.shape.radius = 100

4. Turn on "Visible Collision Shapes" in the debug menu.
5. Install the Rapier2D asset and switch to the Rapier2D physics engine.
6. Run the scene to see that the RigidBody2D gets closer to the StaticBody2D before a collision happens.

Note: The attached zipped project has the above setup.

Expected behavior

The RigidBody2D should land and rest on top of the StaticBody2D. This is also what happens using the Godot 2D physics engine.

Screenshots

Environment (please complete the following information):

• OS: Mac OS
• Version 14.4.1
• Godot Version 4.2
• Type SIMD from Asset Store

Example project(zip)

SettingRadiusHasNoEffect.zip

[TravisBarryDick]

I also just noticed that updating the shape as follows has the intended behavior:

func _ready():
    var new_shape = CircleShape2D.new()
    new_shape.radius = 100
    $CollisionShape2D.set_shape(new_shape)

[Ughuuu]

Interesting. Will investigate, thanks for the bug report.

[Ughuuu]

It seems when a shape is changed, the shape is destroyed and recreated(probably this can be optimized, this seems to be just code ported from godot physics). But the collider is only destroyed, and the shape itself with all properties isn't destroyed. That's why this happens.
I'm trying to also destroy the shape when it needs updating, see if there are any lose ends. If not i'll try to update the shape instead of deleting it.

[Ughuuu]

Ran the tests, there isn't any issue after the change. Seems to fix this. Only issue I could think of with this approach is if there are any dangling references of the shape handle, but the only place the shape handle reference is kept is on the shape itself, so there wouldn't be any problem.
Will take a note of this bugfix for the rust rewrite also and make sure to re-implement it there as well.