Collision shapes overridden in inherited scenes are not used by physics, but display fine.

[need12648430]

Operating system or device - Godot version:
Godot 2.1, built recently from Github's 2.1 branch.

Issue description:
Collision shapes overridden in derived nodes are not used by the physics. They are, however, displayed fine both in the editor and in game with the 'visible collision shapes' option enabled.

Further inspection confirms that the NodePath of the collision shape does point to the base scene's resource while the game is running.

The expected behaviour is of course that the scenes use their own collision shapes when overridden.

Steps to reproduce:
Create a scene with a KinematicBody2D root, and a CollisionShape2D helper node. In that node, create a CircleShape2D resource of radius 32. Save as A.tscn

Create an A.tscn inherited scene, B.tscn. In the inherited CollisionShape2D node, create a new CircleShape2D resource of radius 16. Save.

Create Main.tscnand instance both A and B. Turn on visible collision shapes. Both the editor and running game will show the expected collision shapes. But B will still reference A's collision shape, as you can test with any collision.

Link to minimal example project:
InheritedSceneResources.zip

Remember to turn on visible collision shapes when testing this project. That sprite following the mouse cursor will turn red when over a shape, I figured it'd make the issue easier to see.

If you take a peek at the console, I've printed the shape resources' NodePaths. You'll notice that the NodePath of both shapes are identical.

[eon-s]

Duplicate of related to #5798

[need12648430]

There is a collision shape on the inherited scene, it's just the wrong one. Not a duplicate issue. Check the example.

[eon-s]

@need12648430 right, changed to related, I think all are the same issue with shape resources, like if the inherited uses the base list of shapes/resources when added to the tree.

[need12648430]

I thought so too, but I tried changing the id of the subresource by hand to something distinct in the inherited scene, to no avail. I need to look more into it - it might be related, but not necessarily.

[eon-s]

Looking at the resource ID, both CollisionObjects have the same resource, while the CollisionShapes have different ones.

Base CS reference to the base shape while the other has a new one, that is why you see the correct shape drawn by the helper.

Add this to the for on the example script

print(child.get_shape(shape).get_rid().get_id())
print(child.get_child(0).get_shape().get_rid().get_id())

edit: forcing the CollisionShape to update the parent on ready with a script like this:

func _ready():
	get_parent().set_shape(0,get_shape())

Works in the editor, not sure if an exported on release project too (I don't know how helpers work there)

[reduz]

Still need to fix this in 3.0

…

On Mar 21, 2017 10:43 PM, "eon-s" ***@***.***> wrote: Looking at the resource ID, both CollisionObjects have the same resource, while the CollisionShapes have different ones. Base CS reference to the base shape while the other has a new one, that is why you see the correct shape drawn by the helper. Add this to the for on the example script print(child.get_shape(shape).get_rid().get_id()) print(child.get_child(0).get_shape().get_rid().get_id()) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#8103 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF-Z24wuaclW9Y5YGB13QIsJZmwSEU7Iks5roHzGgaJpZM4MkKt5> .

[need12648430]

Great information and brilliant find, thank you. Even if I can't fix the bug, just forcing the shape to update will save me a lot of refactoring in the meantime.

[need12648430]

@reduz Any advice on patching this one for 2.1? I know you've got your hands full, more than willing to help if possible. :)

[eon-s]

@need12648430 I don't know the origin of the problem, it could be the way instances are initialized and how shapes are added, CollisionShape nodes and tool mode is another bad combination, among other similar issues.

I hope @reduz find a way to solve all these cases with shapes (and others) on 3, even breaking apart the current shape system.

[kubecz3k]

@need12648430 this one rather wont be patched for 2.1, this would break backward compatibility, you manage your shapes manually in 2.1 for example by using clear_shapes(); and add_shape on the area/body node. All issues related to collision shapes not beeing used by body share common case, which is the way how collision shapes are threaded by the engine, it was design decision not the bug. This should be resolved when #2314 and #5798 will be resolved. Leaving open for now, since it might be interesting in the future to test provided use-case/example.

[kubecz3k]

I think this should be fixed now. Can you recheck?

[eon-s]

@kubecz3k the issue seems to be solved on Godot 3 alpha.

[kubecz3k]

@eon-s awesome, thanks for check :)