You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the problem or limitation you are having in your project
We have this issue in a number of places but the easiest to detail out is the core logic for picking up objects in a XR game.
We have written a script (pickable.gd) that extends RigidBody3D that can be used on any RigidBody object to add the logic that allows the user to pick that object up with their hands.
The problem is that we need a number of the build-in properties of our RigidBody3D to have different defaults than the build in ones. For instance, XR Tools relies heavily on objects to be on the correct layer so all the different features work correctly.
For this reason we have also created a scene called pickable.tscn which has the proper default settings. The correct process is to inherit this scene, and then add all the user components to this (mesh, collision shape, etc).
Users are allowed to stray away from this but the default ensure that everything works correctly.
The problem we now encounter is twofold:
When you import GLTF files, and set those up correctly, the node tree already has a RigidBody3D and CollisionShape3D build in. The correct way of working here would be to assign the pickable.gd script to the RigidBody3D in the imported scene. However doing so does not setup the new default properties.
We very often deal with support questions from people who are porting existing games to VR and thus already have assets with RigidBodies and Collisions setup correctly. They simply want to add the script but again find that things break because this method of working does not set the correct defaults.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
It would be great to have a mechanism to override default values on build-in properties of build-in nodes in script.
So something like:
There was a comment I made a while ago but I cannot find it. From what I remember of it:
I think a general-use @override annotation would be nice for this. It'd work for built-in and script properties, and allow overriding a property down to its own @export annotation (as if it were an implicit _validate_property().
Seeing there have been several different suggestions for this, there does seem to be a real need, but I guess we're having trouble coming to a solution everyone is happy with.
My understanding of the GDScript parser is still very limited so I have no idea what even is possible here.
Describe the project you are working on
Toolkit for XR interactions
Describe the problem or limitation you are having in your project
We have this issue in a number of places but the easiest to detail out is the core logic for picking up objects in a XR game.
We have written a script (
pickable.gd
) that extends RigidBody3D that can be used on any RigidBody object to add the logic that allows the user to pick that object up with their hands.The problem is that we need a number of the build-in properties of our RigidBody3D to have different defaults than the build in ones. For instance, XR Tools relies heavily on objects to be on the correct layer so all the different features work correctly.
For this reason we have also created a scene called
pickable.tscn
which has the proper default settings. The correct process is to inherit this scene, and then add all the user components to this (mesh, collision shape, etc).Users are allowed to stray away from this but the default ensure that everything works correctly.
The problem we now encounter is twofold:
pickable.gd
script to the RigidBody3D in the imported scene. However doing so does not setup the new default properties.Describe the feature / enhancement and how it helps to overcome the problem or limitation
It would be great to have a mechanism to override default values on build-in properties of build-in nodes in script.
So something like:
So we no longer need to rely on people inheriting our scene purely to get the correct defaults.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
See above
If this enhancement will not be used often, can it be worked around with a few lines of script?
There is no way to do this in script.
Is there a reason why this should be core and not an add-on in the asset library?
There is no way to embed this logic in an add-on
The text was updated successfully, but these errors were encountered: