Feature Request - Sprint Toggle in Direct Movement

[teddybear082]

Another feature players commonly need in games is sprinting. I modified the Direct Movement function in the latest stable release (2.3.0) to support:

• Choosing whether to allow sprinting or not
• Choosing whether to enable "hold the button" to sprint or "toggle button" to sprint
• Choosing the sprinting button

I believe the file should be plug and play by just swapping out the 2.3.0 release-version Direct Movement function file but would be good if others could test that. The "max_speed" variable has now been replaced with a "speed" variable and variables for "default_speed" and "sprint_speed" has been added. I don't think this has any tangential unwanted impacts on any other movement functions.

https://drive.google.com/drive/folders/1osoVU7tWHyNJwMDtK8jpxOt9aVN4Rsgb?usp=sharing

(Looks like we can't upload directly .gd files here, so sharing via google drive, should be the "Function_direct_movement.gd" file.)

It would be neat if this type of functionality was added to the main public release, with cleaner and better code than I can create as a newbie.

[Henodude]

The google drive link doesn't work for me.

[teddybear082]

https://drive.google.com/drive/folders/1osoVU7tWHyNJwMDtK8jpxOt9aVN4Rsgb?usp=sharing @Henodude let me know if this one works not sure what happened.

[Henodude]

@teddybear082 The link works now, thanks

[teddybear082]

Great thank you for testing, not sure how I wound up posting a bad link before but this one was definitely different, so I edited the original post. Let me know if the file works for you too!

[Malcolmnixon]

I was playing with this as best as I can (I have a flakey VR controller at the moment), and I think there needs to be a common concept of "is_sprinting" rather than one private to each controllers Function_Direct_movement instance. It feels weird to have the left-hand be "sprinting" and the right hand be "walking".

One solution would be to move "is_sprinting" to the PlayerBody, but that object is starting to turn into a large repository of player state information. I already did this once for jumping, but its still ugly.

The general state-sharing problem occurs for a few movement providers:

• Direct Movement: 2x controller Function_Direct_movement instances
• Jumping: 2x controller Function_Jump_movement instances and 1x Function_JumpDetect_movement under the ARVROrigin

It may be better to have PlayerBody support storing arbitrary state information for the movement providers in a public state dictionary. Thoughts?

[Malcolmnixon]

I added a new issue https://github.com/GodotVR/godot-xr-tools/issues/120 to add a means for sharing state information. This would clean up the "is_sprinting" state, but would also be beneficial for other movement providers.

[teddybear082]

@Malcolmnixon first of all thank you SO MUCH for creating these tools. I finally feel like I made a real (simple) VR game for the first time solely because of your and Bastian's work.

Anyway, I both agree and disagree. Where I come out is in the near term, I don't think you need to rework everything to have really good playable options but in the long term for some fringe cases sharing the state may be necessary.

The reason I don't think there's a need for a big change immediately is that having sprinting and jumping paired to the controller isn't really that big of a deal provided that (as per a different issue I posted: #115 ) you separate out turning from the direct movement module into its own "turning" module by stripping out the strafing and movement from the code. Jumping is already a separate module. If turning is on its own module, as a practical matter no one would have the direct movement module on more than one hand. At most you would have teleport on one hand and direct movement on the other. Similarly, someone wouldn't typically unnecessarily take up a button by putting more than one jump button .

Examples of most common control schemes:

• Direct Movement + sprint on one hand, turn and jump on the other hand: This can be accomplished under the current scheme if the modifications to the turning file are made and modifications to direct movement for sprint are made.

• Teleport on one hand, jump on the same or different hand: This can be accomplished under the current scheme.

-Rarer: Direct movement plus sprint on one hand, teleport on the other, jump on one or the other hand : This can be accomplished under the current scheme with the proposed changes.

So there would not be an issue of duplicative states in 99% of practical use cases. And in the rare event someone did duplicate jump buttons or direct movement modules maybe that is because they would want one hand to have the "extra power" jump or sprint movement only when using the specific hand in which case having controlled by a universal variable might be problematic.

But I guess in the long term to give even more button mapping options may be still good to switch to a system of state information sharing, for instance if someone wanted to sprint with their right hand but move with their left. Would you think you would just share state information with signals or something else? I assume figuring out if there was a conflict and resolving it could be done with signals...

[Malcolmnixon]

@teddybear082 I think splitting the turning from the direct movement is an excellent idea, and I'll get that one in first as it will simplify the next steps.

I tend to configure my players using two Direct Movement providers as follows:

• Left = Direct Movement configured for move/strafe
• Right = Direct Movement configured for move/rotate This comes from me playing way too much Population One which uses that style, so it's tainted what I feel as "natural" ;)

I should be able to get something in place fairly soon for this.

[teddybear082]

That’s really funny because PopOne is like the only “must have” game I don’t have for VR hehe.

---

From: Malcolm Nixon @.> Sent: Tuesday, April 19, 2022 8:58 PM To: GodotVR/godot-xr-tools @.> Cc: teddybear082 @.>; Mention @.> Subject: Re: [GodotVR/godot-xr-tools] Feature Request - Sprint Toggle in Direct Movement (Issue #119)

@teddybear082https://github.com/teddybear082 I think splitting the turning from the direct movement is an excellent idea, and I'll get that one in first as it will simplify the next steps.

I tend to configure my players using two Direct Movement providers as follows:

• Left = Direct Movement configured for move/strafe
• Right = Direct Movement configured for move/rotate This comes from me playing way too much Population One which uses that style, so it's tainted what I feel as "natural" ;)

I should be able to get something in place fairly soon for this.

— Reply to this email directly, view it on GitHubhttps://github.com/GodotVR/godot-xr-tools/issues/119#issuecomment-1103316257, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUZKG4IYZ6UKW3H7AOWV473VF5JENANCNFSM5TNQXNAA. You are receiving this because you were mentioned.Message ID: @.***>

[teddybear082]

@Malcolmnixon putting this here because also related to direct movement. I started a port of NeoSparks' Walk in Place Locomotion beta. The .tscn and .gd are here: https://drive.google.com/drive/folders/1osoVU7tWHyNJwMDtK8jpxOt9aVN4Rsgb?usp=sharing

Good news is since it is just head movement you don't have to worry about your controller! :)

It "works" but its not entirely smooth and one thing that bugs me is that I feel like, based on the Function_Direct_movement.gd script, the calculation of motion/speed should be operating on the player_body.ground_control_velocity.y value. But right now it seems to work best as the code was actually written, operating on the ARVROrigin instead (see line 216 of the Locomotion_WalkInPlace.gd). I know the other movement modules do not operate on the ARVROrigin so I feel like there should be some way to translate this to the player_body velocity code. Just not sure how.

Another disconnect that bugs me is that the original code (and thus the port for now) calculates player height with this function: func get_current_player_height(): return vrCamera.global_transform.origin.y - vrOrigin.global_transform.origin.y

However, I see in the OpenXR playerbody function you seem to calculate the player height as: player_body.camera_node.transform.origin.y + player_body.player_radius so I wonder if I should be using that equation instead whenever the WalkInPlace code wants to calculate height. I think I saw on the XR-tools-demo you have a working prototype of physically jumping to jump so this would be cool to get working with that someday. Overall I feel like if I export enough variables this should be something that can be tweaked by individual devs how they want it. Anyway if you get a chance to take a look let me know what you think.

EDIT: I have github links now; the google drive ones are outdated for these locomotion options: https://github.com/teddybear082?tab=repositories

[teddybear082]

Closing this issue as now sprinting node has been implemented into XR tools as its own node.