Forcing player to move

Simple question, and. would suppose a simple answer however from past experience i’m normally wrong on this.

How do I force the player to move forward, given I still want them to be able to control themselves, but I wish to force them to be moving at all times

The effect im going for is identical to the game ‘run’

If you have never played that Where did your childhood go try it here

1 Like
  1. Remove the bind of the Up & Down keys
  2. Constantely move the player with CFrame
  3. Keep the Left & right keys.
1 Like

Yes, but how he would do that? Otherwise, he wouldn’t post this thread.

1 Like

I’m telling him how-to do that.

Too ‘hacky’ a solution for my liking

Check this: Auto running script


Heya thanks for responses!

In normal scenarios @myaltaccountsthis’s solution works perfectly (I tested on a normal baseplate)

However, since I’m playing with @EgoMoose’s Gravity controller something involving platform stand seemed to cause it to break, therefor instead my solution was to modify this script
Screen Shot 2020-02-21 at 23.03.04

Like this (bottom function exemplar of how it should have roughly looked)

Which effectively does not register when the user wishes to stop moving and therefor will continue to move the user till death / leaving.

Kinda a tacky solution, but met my needs. Thanks once again for the solutions!

Ah so given your specific usage. I figure it’s worth elaborating on why you have to do this workaround.

The most ideal way to get input for a controller that would coexist with other scripts would be to use the Humanoid.MoveDirection property. This is because it’s grabbing the directional output after it’s been sent to the humanoid. The issue with this is that this direction is exclusively lateral relative to world space. That means it’s not very useful to us given that in a arbitary gravity situation we may need to go up or down.

So the way that I handle input is to get the local move vector and then convert it to world space myself thereby properly handling the potential vertical aspect. It just so happens that the PlayerModule has a way to grab this local move vector quite easily. The trade off is that this input is as RAW as the WWE meaning it’s only looking at the keyboard input, not anything you pass into the humanoid manually e.g. via the :Move() method.

So what would be a prettier solution?

Instead of going into the player scripts modules we can adjust the gravity controller to be a bit more lax as to where it gets its input from. Originally I wrote it such that it pulls this local move vector directly from the control module, but I’ve updated the place to instead pull the move vector from a method in the gravity controller which defaults to the raw input.

This means you can now overwrite this publically exposed method with whatever vector you want.

For example:

local GravityController = require(GravityControllerModule).new(myLocalPlayer)

function GravityController:GetMoveVector()
	local default = self.Controls:GetMoveVector()
	return, 0, -1)

-- anything else...

Hope that helps/makes sense! :+1: