GDExtension: several methods in OpenXRHand, SkeletonIK3D, VisualShaderNodeComment unavailable

[Bromeon]

Tested versions

• Reproducible in 4.3.dev.custom_build.655e93d58

System information

Both Windows 10 and WSL 2 (Ubuntu 20.04)

Issue description

The following 8 methods are listed in extension_api.json as of recent master, however their function pointers can't be retrieved:

OpenXRHand::set_hand_skeleton (hash 1348162250)
OpenXRHand::get_hand_skeleton (hash 4075236667)
SkeletonIK3D::set_interpolation (hash 373806689)
SkeletonIK3D::get_interpolation (hash 1740695150)
VisualShaderNodeComment::set_title (hash 83702148)
VisualShaderNodeComment::get_title (hash 201670096)
VisualShaderNodeComment::set_description (hash 83702148)
VisualShaderNodeComment::get_description (hash 201670096)

Are these classes marked experimental?

Even if that's the case, their availability in GDExtension should generally match the advertised values in extension_api.json.

For a similar issue in the past, see e.g. #86206.

Steps to reproduce

Try to fetch any of the above class methods through GDExtension, you will get a null pointer.

Minimal reproduction project (MRP)

N/A -- but recently failed CI run.

[akien-mga]

These methods were fully removed without registering compatibility bindings in #88014 and #87888 it seems.

CC @Geometror @TokageItLab

[dsnopek]

Hrm. I remember PR #87888 registering compatibility methods for OpenXRHand the last time I reviewed it (I remember noting that compatibility methods weren't necessary for XRHandModifier3D because it was new in Godot 4.3), but it looks like they were removed in the last rewrite.

[BastiaanOlij]

Hrm. I remember PR #87888 registering compatibility methods for OpenXRHand the last time I reviewed it (I remember noting that compatibility methods weren't necessary for XRHandModifier3D because it was new in Godot 4.3), but it looks like they were removed in the last rewrite.

OpenXRHand should be reverted to how it was working in Godot 4.2.1 and not inherit from SkeletonModifier3D if we're going to change SkeletonModifier3D in this way. The node is already marked as deprecated, it makes no sense to break the ABI of a deprecated node especially when the "new" approach requires structural changes to your application regardless of implementing compatibility methods.

I do not agree with the recent changes of SkeletonModifier3D as it's breaking too many things on the XR side and requiring us to seriously change our approach (to the point where I'm contemplating that we should break away from the animation system entirely and duplicate all the logic we do share, which would be a shame).

[akien-mga]

Fixed by #90759, #90780, and #90797.