OQ_ButtonPressable

[shafy]

Adds a scene and script with a (physically) pressable button. Features:

• Setable press distance (how deep you need to press it)
• Choosable materials for on and off state
• Bool if initial state is off or on (off is default)
• Emits button_pressed signal

To be added/improved:

• If you remove hand slowly, it jitters a bit
• Press/click sound

[shafy]

From the source I'm not sure if I fully understand how it should be used. My proposal on how to make it usable would be to make it a scene that can be a child to a spatial and makes its parent a pressable button.

In its current version it's usable as is (you just instance it, and it includes the mesh and area/collision shape). This is convenient, but maybe a pain if you want to change the Mesh (right now it just has a default BoxMesh).

Here are some option we should quickly discuss:

Option 1 If I understand correctly, in your suggestion the user would create a parent node (Spatial), add a child node (his own Mesh), and another child (OQ_ButtonPressable)? This gives more flexibility, but also takes longer to set up.

Option 2 Another option could be to accept the custom Mesh as a script variable? This way, they can just instance the button and provide the Mesh.

Option 3 A third option is to make it a selectable node from the "Create New Node" menu. It will then instruct the user to add a Mesh and Area with the warning triangle (like a RigidBody does e.g.). This is probably my favorite option and seems most in line with how Godot works, so this should be the most intuitive way to go?

Let me know what you think.

[NeoSpark314]

Agreed that having automatically create a default button is nice and is how the toolkit should work (minimal setup to make things work for fast prototyping). Let's do this for now and later add a boolean flag that we call use_parent_as_button that then does not create the default button but modifies the parent (would be Option 1).

I think option 2 is hard to use as it is not easy to have a preview in the editor on how it will look.

Regarding Option 3; I think the scene drag-n-drop (what the toolkit does at the moment) makes it easier to use as features are already grouped in folders that show where they should be applied. Maybe at some point in the future we try to extend it to register each type for godot; but this probably makes only sense once the actual API and feature set is more stable. At the moment fast iteration and trying different features is more important to me.