Tips on how to make a hover car go up and down

Help and Feedback Scripting Support
#1

I have this hover car. It is able to go forward, backward, left and right. However, my main issue now is to make it so that it will be able to go down when the user presses the up and down arrow key on the keyboard. I have thought of a few solutions to this:

  • I can possibly change the values of either BodyAngularVelocity, BodyForce, BodyGyro or BodyPosition and experiment which would make it go down and up

  • Create a lengthy script Probably will be inefficient and laggy at the same time, can be a huge time waster.

  • Using of mouse:KeyDown() and create a lengthy script Again, I think this would make it look choppy

Other than these few, I can’t really think of anymore. Do you guys have any tips on this?

4 Likes
#2

You can create function for going Up and Down that changes a single value that can be set as the height where the vehicle is at. And to get a smoothing effect just Lerp the value. LMK if u need me to elaborate

#3

You could make a default height variable in the script.
If the vehicle is spawned at a certain height, store it in a variable.

When a key is held down you increase/decrease this value slowly and change the bodyposition’s Y axis.

Make sure to check if the vehicle’s current height is near that of the variable to avoid the number being able to go up/down infinitely and make your car get stuck in the floor or something because a player held down for too long.

#4

Hmm i could possibly try that when I get home. Thanks :))

1 Like
#5

This post was flagged by the community and is temporarily hidden.

#6

Hi, may you elaborate? Thanks :slight_smile:

1 Like
#7

For example you could something like

local RunService = game:GetService("RunService")
local up = 0

function MoveUp(action_name, action_state)
      if action_state == Enum.UserInputState.Begin then
            up = up + 1
      end
end

function MoveDown(action_name, action_state)
      if action_state == Enum.UserInputState.Begin then
            up = up - 1
      end
end

RunService:BindToRenderStep("Update", Enum.RenderPriority.Input.Value, function()
      HoverCar.PrimaryPart.CFrame = CFrame.new(0, up, 0)
end)

ContextActionService:BindAction("Up", MoveUp, false, "q")
ContextActionService:BindAction("Down", MoveDown, false, "e")

and Lerp the CFrame value to make it smooth out by doing this

HoverCar.PrimaryPart.CFrame = HoverCar.CFrame:Lerp(CFrame.new(0, up, 0), 0.5)
#8

That probably wouldn’t work because I assume Kawaii is using BodyMovers as her original post implies but I’m not sure. Not to mention you are setting the cframe to (0, height, 0) which would always be in the center of the map. Also, your example Lerp has a static alpha meaning it won’t go up to the desired height.

As for @KawaiiX_Jimin, are you using BodyMovers? If so, you could probably change the BodyPosition’s Y to the desired height. Y is the height of the BodyPosition.

bodyPosition.Position = Vector3.new(posX, height, posZ)
2 Likes
#9

I was only giving him a possible solution with a jist of how it works, obviously its not gonna work exactly but it does work the way its intended. as for if he’s using body movers, if he wants to add any tilting effects hes going to need to do it with cframing either way so its better he do it with cframes than with body movers since they are limited to what they can do

#10

No? You can tilt and rotate with BodyGyros. You do not need to use CFrame and, in my opinion, you shouldn’t.

1 Like
#11

U can tilt but its wonky and doesnt allow for the same control

#12

…? What?

Could you explain what you mean by this? I don’t think body movers are restricted. Body movers and CFrames also both support vector quantities.

I’m asking about what you’re saying in genuine curiosity, since I’m not too sure what you mean. It can also be confusing for others who read it and don’t see an appropriate rationale or example of what you’re talking about.

1 Like
#13

Generally Body Movers are good for doing alot Basic things like changing a position of an object without going too much into programming CFrames and stuff like this. But to go alot of functionality like control on tilt influence and stuff like that working with CFrames is better, It provides u the programmer more control and Leaves less for the roblox physics to worry about. Not for those who would argue the Physics engine is there for a reason. The engine has been known to be unreliable with alot of things so people tend to create their own solutions with CFrames and Vectors. A general jist would that using CFrames is a better way to go so that u can get the utmost functionality out of your work and really make something unique.

#14

…?

Both are used in or are manipulated by code. Body movers can also be used for complex structures - their simplicity is dependent on your use case, not on the object itself. CFrame is a data type. Body movers apply physics to objects.

Still don’t understand what you mean by this. You as the developer have control either way. There is no more or less control. Just use the object properly.

But those are just data types? You still need a way to apply movement. This is a hover car. The physics engine is involved either way because you’re using parts. What basis are you going off of?

No that’s not a gist, that’s confusing. What do you mean? You can still use a vector with a CFrame. You can still use CFrames and/or vectors while using body movers. Your point is extremely confusing. Body movers are fine.

#16

I think you’re ignoring what he is saying. CFrame is not a good solution for hover cars, or any cars. They can cause issues with other physics, such as the Humanoid. You, in most cases, should use BodyMovers unless you have a specific use case to not use them.

#17

Ive never heard of CFraming having any issues with Humanoid so I would love to see where you got this information from

#18

There indeed are a few issues related to that. For example moving a platform with CFrames wont move the player(s) standing on it. This is why for example jailbreak had to change the CFrame of the player along with their train.

Video demonstration by @fireboltofdeath:

tl;dr you shouldn’t use CFrame for cars for the same reason your character isn’t loop teleporting forward when you walk.

#21

This is a topic on hover cars, not humanoids, so this is off-topic and irrelevant. Please stay on-topic.

The point I’m trying to make is that this is a hover car, yes? That means physics are a heavy tie in to this system - or any movement system, really. If you’d like to spend many days writing a custom physics engine that “uses CFrame” (which, again, it’s just a data type), then feel free - the backend physics engine is still going to take effect though.

I’m strongly failing to see what point is trying to be proven here or what the issue against body movers is.

You asked a question which he gave a response to.

2 Likes
#22

I just find it more practical and useful to use CFraming to make a vehicle than Body Movers they can be annoying to deal with in terms of their parameters and the Body Movers API tend to change all the time meaning something could go wrong in the future with it. Atleast with CFraming its a more solid solution that has proven to work for many different things.

#23

Can you elaborate on this? I havent seen the body movers “api” ever change much?

Also, the fact that you find using CFrames more practical doesn’t mean using body movers is very bad and nobody should ever do it. They are better in terms of the physics engine, since they actually move parts, as opposed to CFraming which simply changes their location without applying momentum forces or such.

2 Likes