Feature request: Provide more signals

[tcrass]

I stumbled over this when I was trying to implement the following behaviour: I want a controller's teleport function to be disabled while the same controler's pointer function is hitting a target. However, I currenly don't see any possibility to determine from "outside" whether the pointer is pointing at a pointable or not -- there seems to be neither a property reflecting the pointer's state, nor (imho the preferred mechanism) a signal notifying about the pointer's state.
Furthermore, I'd like to play different sounds on various function events, like pointer (de-)activation, pointer hitting something, teleporter (de-)activation, teleporter target state change, and actual teleportation. Again, it would be great if signals were available for notifying about all these things.
I suppose it would be generally appreciated if all functions provided signals regarding their specificv state changes.

[Malcolmnixon]

The pointer function exposes the 'last_target' and 'last_collided_at' fields; however it's inefficient to poll them so pull request #502 adds the signals I think you're looking for:

• pointer_entered(target)
• pointer_moved(target, from, to)
• pointer_pressed(target, at)
• pointer_released(target, at)
• pointer_exited(target)

[tcrass]

The pointer function exposes the 'last_target' and 'last_collided_at' fields; however it's inefficient to poll them so pull request #502 adds the signals I think you're looking for:

* `pointer_entered(target)`

* `pointer_moved(target, from, to)`

* `pointer_pressed(target, at)`

* `pointer_released(target, at)`

* `pointer_exited(target)`

Sounds perfect to me!

I guess I could hack something similar into the teleporter function script (already had a brief look into the code), but I absolutely don't know if/when I'll find the time... Anyway, I'd first like to discuss what kind of signals we'd like to have. Perhaps something like

teleporter_activated
teleporter_hit(target, coordinates) # target and coordinates can be null
teleporter_can_teleport_changed(can_teleport)
teleporter_deactivated
teleporter_finished(target, coordinates) # target and coordinates can be null

[tcrass]

OK, I'm on it... My current version of the iterface looks like

teleporter_activated()
can_teleport_changed(can_teleport)
teleported_to(location)
teleporter_deactivated()
teleporter_target_entered(node, at)
teleporter_target_moved(node, from, to)
teleporter_target_exited(node, at)

I've so far implemented the first four signals, but for the last three (the target-related ones) I'll first have to gain a deeper understanding of the current teleport function code as well as Godot 4's physics system. Might happen tomorrow, might as well take another month... ;)

[Malcolmnixon]

Pull request #508 moves the teleport player-movement logic into XRToolsPlayerBody, and the player emits a player_teleported signal after the player moves. This is because the new XRToolsTeleportArea can also teleport a player when the user steps into it.

[BastiaanOlij]

@tcrass were you planning on submitting a PR for those signals? Looks like a worth while improvement of the teleport logic.

[tcrass]

were you planning on submitting a PR for those signals? Looks like a worth while improvement of the teleport logic.

I'm on it: https://github.com/tcrass/godot-xr-tools/tree/499-teleport-signals

I already have some more code additions in my local working copy, but as I said, I just can't predict when I'll be able to finish it up. In a family with three kids, there's always something else popping up demanding your attention...