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
Yes, but how he would do that? Otherwise, he wouldn’t post this thread.
I’m telling him how-to do that.
Too ‘hacky’ a solution for my liking
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
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 Vector3.new(default.x, 0, -1)
end
-- anything else...
Hope that helps/makes sense! 
For any non-programmers out there who aren’t able to strip out the relevant code from the file EgoMoose kindly provided, this is the final result:
local playerModule = require(game.Players.**PlayerName**.PlayerScripts:WaitForChild("PlayerModule"))
local controlModule = playerModule:GetControls()
local humanoid = workspace:WaitForChild("PlayerName").Humanoid
game:GetService("RunService"):BindToRenderStep("move", Enum.RenderPriority.Character.Value + 1, function()
local moveVector = controlModule:GetMoveVector() -- relative to player not world (unlike MoveDirection)
humanoid:Move(Vector3.new(moveVector.X,moveVector.Y, -1), true) --minus thanks to some CFrame LookVector Shenanigans, "true" as we want it to be applied relative to player camera.
end)