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
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.
local GravityController = require(GravityControllerModule).new(myLocalPlayer)
local default = self.Controls:GetMoveVector()
return Vector3.new(default.x, 0, -1)
-- anything else...
Hope that helps/makes sense!